Apache - AuthType Digest - nur Passwort verschküsselt?
Chris
- webserver
Hallo!
Ich hätte da mal eine Frage, die ich per Recherche nirgends so deutlich beantwortet kriege. Mir scheint, dass viele Verfasser es offensichtlich selbst nicht so genau zu wissen scheinen.
Und zwar geht es um die Benuzer-Authentifizierung per AuthType Digest.
Ich lese immer wieder, dass sinngemäß "die Anmelde-Daten" verschlüsselt werden. In manchen Publikationen steht ausdrücklich, dass sowohl Benutzername als auch Passwort verschlüsselt werden.
Nun habe ich sowohl den Fiddler als auch den Proxomitron als HTTP-Proxies zwischengeschaltet, um die HTTP-Header mitzulesen.
Bei AuthType Basic werden sowohl Benutername als auch Passwort - durch einen Doppelpunkt getrennt - per Base64 kodiert. Ein Script, was mir das wieder decodiert, habe ich mir schon vor einiger Zeit selbst geschrieben.
Erstaunt hat mich aber, dass bei AuthType Digest zwar das Passwort per MD5 verschlüsselt wird, der Benutzername hingegen einfach im Klartext übertragen zu werden scheint. Oder habe ich die Ausgabe der Header missinterpretiert?
Das wäre doch schon eine potentielle Sicherheitslücke. Damit könnte ein Angreifer nämlich einfacher an den Benutzernamen kommen. Gibt es irgendwelche zwingenden Gründe, warum das Passwort nicht verschlüsselt wird?
Da ich teils sehr schnell tippe, ohne auf den Bildschirm zu schauen, kann es schon mal passieren, dass ich die Tab-Taste nicht richtig erwische. Dann stehen Benutzername und Passwort beim Benutzernamen, welcher dann also unverschlüsselt abgeschickt würde. Demnach hätte ich das Passwort damit doch schon quasi "verheizt"!?
Gibt es vor diesem Hintergrund sicherere Verfahren als AuthType Digest?
Da ich Internet über Kabel-TV und damit eine quasi-fixe IP habe, könnte ich die Authentifizierung auch auf eine IP beschränken. Ist aber nicht unbedingt so bequemen, falls man das nach einem IP-Wechsel wieder ändern müsste. Und ist das wirklich 100% sicher?
Was ist mit SSL? Afaik wird damit doch nur der Datenverkehr "der Internet-Seite" über das HTTPS-Protokoll verschlüsselt? Oder würde auch schon die Authentifizierung komplett - also auch der Benutzername - per SSL verschlüsselt werden? Apache kennt das SSL-Modul doch? Kann es bereits hierfür darauf zugreifen?
Oder gibt es da sonst noch was?
Ich könnte auch per PHP eine Anmelde-Seite erstellen. Aber da hinter diesem Vorhang Blogs und andere komplexe Scripten laufen sollen, habe ich erst überhaupt keine Lust, da rumzumanipulieren.
MfG
Chris
Guten Tag,
Ich hätte da mal eine Frage, die ich per Recherche nirgends so deutlich beantwortet kriege. Mir scheint, dass viele Verfasser es offensichtlich selbst nicht so genau zu wissen scheinen.
Und zwar geht es um die Benuzer-Authentifizierung per AuthType Digest.
Ich lese immer wieder, dass sinngemäß "die Anmelde-Daten" verschlüsselt werden. In manchen Publikationen steht ausdrücklich, dass sowohl Benutzername als auch Passwort verschlüsselt werden.
So wie ich den entsprechenden RFC verstand, wird nur das Password verschlüsselt und nicht der Name des Users (username).
Bei AuthType Basic werden sowohl Benutername als auch Passwort - durch einen Doppelpunkt getrennt - per Base64 kodiert.
Das ist ja bekannt.
Erstaunt hat mich aber, dass bei AuthType Digest zwar das Passwort per MD5 verschlüsselt wird, der Benutzername hingegen einfach im Klartext übertragen zu werden scheint. Oder habe ich die Ausgabe der Header missinterpretiert?
Nein, das ist so korrekt und kann ich bei den Ressourcen, die ich mit Digest-Auth schütze, auch nachvollziehen.
Das wäre doch schon eine potentielle Sicherheitslücke. Damit könnte ein Angreifer nämlich einfacher an den Benutzernamen kommen. Gibt es irgendwelche zwingenden Gründe, warum das Passwort nicht verschlüsselt wird?
Das Passwort wird verschlüsselt, der Username nicht.
Da ich teils sehr schnell tippe, ohne auf den Bildschirm zu schauen, kann es schon mal passieren, dass ich die Tab-Taste nicht richtig erwische. Dann stehen Benutzername und Passwort beim Benutzernamen, welcher dann also unverschlüsselt abgeschickt würde. Demnach hätte ich das Passwort damit doch schon quasi "verheizt"!?
Das ist allerdings kein Problem des Authentifizierungsverfahrens. Man sollte schon aufpassen, was man wo eingibt.
Gibt es vor diesem Hintergrund sicherere Verfahren als AuthType Digest?
Du könntest HTTPS verwenden. Dann kannst du auch unbesorgt Basic-Auth verwenden.
Was ist mit SSL? Afaik wird damit doch nur der Datenverkehr "der Internet-Seite" über das HTTPS-Protokoll verschlüsselt? Oder würde auch schon die Authentifizierung komplett - also auch der Benutzername - per SSL verschlüsselt werden? Apache kennt das SSL-Modul doch? Kann es bereits hierfür darauf zugreifen?
Bereits die Authentifizierungsdaten sind verschlüsselt. Die Verschlüsselung findet jeweils auf Layer 3 (Transportschicht) statt und ist für die darüber liegende Anwendungsschicht transparent.
Oder gibt es da sonst noch was?
VPN, SSH.
Gruß
Christoph Jeschke
So wie ich den entsprechenden RFC verstand, wird nur das Password verschlüsselt und nicht der Name des Users (username).
Den Artikel kannte ich noch nicht. Dazu aus offizieller(er) Quelle. Noch mehr zu lesen.
Das Passwort wird verschlüsselt, der Username nicht.
Oh! Hier habe ich mich vertan, sollte natürlich genau anders rum sein.
Das ist allerdings kein Problem des Authentifizierungsverfahrens. Man sollte schon aufpassen, was man wo eingibt.
Das ist richtig. Kann aber dennoch (leicht) passieren. ;-) Und warum nicht schon der Benutzername verschlüsselt wird, bleibt mir immer noch rätselhaft. Immerhin ist es damit leichter, schon mal an den Benutzernamen zu kommen.
Du könntest HTTPS verwenden. Dann kannst du auch unbesorgt Basic-Auth verwenden.
Mit HTTPS habe ich das Spielchen mit dem Abhören der Header noch nicht ausprobiert. Das werde ich dann ebenfalls mal ausprobieren. Klingt soweit eigentlich logisch, dass die Authentifizierung von HTTP- auf HTTPS-Header umgestellt wird. Aber da man nie wissen kann, ... frage ich lieber. ;-)
Manchmal ist es gut, sich einfach mal mit jemandem austauschen zu können.
Bereits die Authentifizierungsdaten sind verschlüsselt.
Dann werde ich SSL installieren.
Oder gibt es da sonst noch was?
VPN, SSH.
SSH benuze ich, um auf den Server zu kommen. D.h. zur Wartung der Maschine. Aber kriegt man damit auch die Authentizierung dem Apache gegenüber via Browser hin?
Mit VPN muss ich mich noch beschäftigen.
Danke!
Chris
Guten Tag,
Und warum nicht schon der Benutzername verschlüsselt wird, bleibt mir
immer noch rätselhaft. Immerhin ist es damit leichter, schon mal an den
Benutzernamen zu kommen.
Was ja nicht schlimm ist, wenn das Passwort ausreichend gut gewählt ist. Ist es das nicht, ist es IMHO eh egal. Denn der Username ist meist keine kryptische Zeichenkette.
Mit HTTPS habe ich das Spielchen mit dem Abhören der Header noch nicht
ausprobiert. Das werde ich dann ebenfalls mal ausprobieren. Klingt soweit
eigentlich logisch, dass die Authentifizierung von HTTP- auf HTTPS-Header
umgestellt wird. Aber da man nie wissen kann, ... frage ich lieber. ;-)
Dazu musst du aber den Datenstrom direkt mitschneiden, beispielsweise mit tcpdump oder Wireshark. Denn wenn die Daten in deinem Browser ankommen, sind sie schon entschlüsselt. Es wird übrigens nicht von HTTP- auf HTTPS-Header umgestellt, sondern HTTP wird eine Netzwerkschicht tiefer zusätzlich verschlüsselt. An dem verwendeten Protokoll ändert sich erst mal nichts.
SSH benuze ich, um auf den Server zu kommen. D.h. zur Wartung der
Maschine. Aber kriegt man damit auch die Authentizierung dem Apache
gegenüber via Browser hin?
Man kann mit SSH einen Tunnel aufbauen und über diesen verschlüsselt kommunizieren. Das funktioniert dann so ähnlich wie ein VPN.
Gruß
Christoph Jeschke
Dazu musst du aber den Datenstrom direkt mitschneiden, beispielsweise mit tcpdump oder Wireshark. Denn wenn die Daten in deinem Browser ankommen, sind sie schon entschlüsselt.
Gut zu wissen, sonst hätte ich mich noch gewundert. ;-)
Man kann mit SSH einen Tunnel aufbauen und über diesen verschlüsselt kommunizieren. Das funktioniert dann so ähnlich wie ein VPN.
Das werde ich demnächst alles mal ausprobieren.
MfG
Chris