nicht angemeldet
Hallo!
ein per "Basic" aufgeschnapptes Passwort kann ich mit
meinem Browser verwenden. Ein per Digest aufgeschnapp-
tes nur mit einem Programm, das HTTP beherrscht.
Aber das größer Problem ist jawohl HTTP-Traffic zu belauschen, als Tools wie curl zu bedienen, oder? Außerdem darf man auch bei digest nicht auf SSL verzichten, und wenn jemand da dran kommt, dann ist das bestimmt jemand der lieber http von Hand über Telnet schreibt, als einen Browser zu benutzen!
liegt es daran das das Passwort mit crypt()
verschlüsselt wurde?Digest verwendet MD5 - kein crypt.
Ja, das hatte ich auch gelesen, konnte aber in der Apache Doku weder finden wie genau basic-Passwörter abgespeichert werden, wenn man nicht das hauseigene Tool verwendet, bei digest nur wie es übetragen wird, halt md5. Natürlich habe ich auch die md5-Prüfsumme mal als Passwort gespeichert, aber das hat genauso wenig funktioniert.
In der Doku finde ich dazu nichts, da steht nur das
eigene Tool beschrieben, und das habe ich hier
nicht.Warum nicht?
Weil ist gerade mein linux nicht vor mir hatte und mein Webserver(provider) das nicht installiert hat.
Wenn Du einen Apache hast, dann sollte es dabei sein.
(Ich habe das Tool unter Windows verwendet, um mir eine
Beispiel-Digest-Konfiguration zu bauen und alle Browser
damit zu testen; daher wußte ich das mit Mozilla 0.9.7
- leider zu spät für sämtliche Netscape 6.x ... kann
sich jemand leisten, Netscape 4 und 6 auszuschließen?)Wenn Du allerdings irgend eine andere Möglichkeit hast,
MD5 auf Deine Kombination aus Benutzername und Passwort
anzuwenden, könnte das auch funktionieren.
auf die Kombination? Das mache ich bei eigen-Konstruktionen von Logins, bei digest habe ich sozusagen "user:md5(pass)" gespeichert. Wobei mir meine eigene Variante(SSL/PHP/SessionID/md5(pass:user) speichern/evtl. Clientseitig Passwort vor Übertragung md5 verschlüsseln) mit der Zeit immer besser schmeckt, denn hierbei wird nicht jedesmal user und pass mitgeschickt, sondern eine SessionID, was auf alle Fälle schonmal besser ist! Außerdem schwerer zu erraten. Die wichtigen Daten werden nur einmal übertragen und dann serverseitig verglichen und sind dann nur für den Server erreichbar. Wenn das ganze mit Session und am besten session-cookie gut gemacht ist ist das erheblich besser als die HTTP-Authentification. Das einzige Argument für diese ist eigentlich, das auch Anfänger da nicht viel falsch machen und ohne viel Hintergrundwissen schon einen recht guten Schutz erreichen, und vielleicht noch das man nicht auf cookies angewiesen ist, denn eine SessionID im GET-String zu übertragen ist nicht das gelbe vom Ei, außerdem lassen sich mit einer serverseitigen Methode nur Scripte schützen, kein HTML, und und andere Formate. Es sind halt verschiedene Anwenungsbereiche, das muß man dann wohl von der Situatuion abhängig machen, wofür man sich entscheidet, nur den großen Vorteil von Digest sehe _ich_ nicht, bei näherer Betrachtung ist das eher ein vordergründiger Vorteil.
Viele Grüße
Andreas