nicht angemeldet
MD5-Verschluesselung (ist das sicher?)
Hallo,
habe mir den Feature-Artikel von Ralf Mieke zum Thema MD5-Verschlüsselung von Login-daten mit Javascript angeguckt http://aktuell.de.selfhtml.org/artikel/javascript/md5/index.htm.
Wenn ich es richtig verstehe, wird dort ein verschlüsselter String, der beim Client aus dem eingegebenen Usernamen und Passwort generiert wird, an den Server geschickt. Der Server müsste dann aus dem ihm bekannten Usernamen und Passwort auf gleiche Weise einen String generieren, und diese vergleichen.
Ich frage mich, was daran sicher sein soll.
Jeder, der den verschlüsselten String "aus dem Netz fischt", kann ihn auch weiterhin dazu benutzen, sich am Server anzumelden, auch, wenn ihm Username und Passwort unbekannt sind...
Danach wäre ein solches login nicht sicherer als z.B. die Übertragung des Usernamen und Passwortes im Klartext mit POST.
Mache ich da irgendeinen Denkfehler?
Gruß
Henk
-
Hallo Henk,
Danach wäre ein solches login nicht sicherer als z.B. die Übertragung des Usernamen und Passwortes im Klartext mit POST.
Mache ich da irgendeinen Denkfehler?glaube ich nicht (das mit dem Denkfehler). Das war mir auch so durch den Kopf gegangen. Das einzig "sicherere" daran ist, dass eben Benutzername und Passwort nicht direkt gelesen werden können und damit zumindest nicht sofort persönliche Daten des Benutzers preisgegeben werden (z.B. könnte das Benutzername/Passwort-Paar auch woanders benutzt werden).
Genauso ist es ja mit Session-IDs. Eine Session von irgendwem zu übernehmen ist ein leichtes, wenn man einfach die Session-ID aus dem Netz fischt. Meistens jedenfalls wird als Akzeptanzkriterium am Server wirklich nur diese ID herangezogen. Wenn man weitere Kriterien wie z.B. User-Agent-String herzieht macht man die Übernahme zwar ein wenig schwerer (ein Angreifer muss eben diese Daten auch mit übergeben), aber nicht unmöglich. Und die IP-Adresse scheidet als Kriterium aus, weil es gerade bei längeren Sessions gerne mal zu einem Wechsel der IP z.B. durch Neueinwahl oder durch mehrere Gateways eines Firmennetzes kommt. Und selbst die kann ja gefälscht sein.
viele Grüsse
Achim Schrepfer -
Hallo Henk,
Mache ich da irgendeinen Denkfehler?
Naja, keinen direkten Denkfehler... Es fehlen Dir lediglich ein paar Informationen. Man kann MD5 nicht umkehren. D.h. es gibt nur en encoding, kein decoding.
Folglich hat der Spion ja nur die verschlüsselte Version des Passwortes. Damit kann er aber nix anfangen, da das bereits verschlüsselte Passwort bei der Eingabe in das Passwortfeld NOCHMAL verschlüsselt wird. Dabei kommt dann nicht wieder das original Passwort raus. Alles logo?schönen Grußs aus Trier
Peter-
Hi Peter,
Folglich hat der Spion ja nur die verschlüsselte Version des
Passwortes. Damit kann er aber nix anfangen, da das bereits
verschlüsselte Passwort bei der Eingabe in das Passwortfeld
NOCHMAL verschlüsselt wird. Dabei kommt dann nicht wieder
das original Passwort raus. Alles logo?warum sollte der Spion das Passwortfeld verwenden?
Er kann doch einfach den URL absaugen (LWP::UserAgent etc.)
nd den belauschten Header mit senden.Viele Grüße
Michael-
Moin Michael,
warum sollte der Spion das Passwortfeld verwenden?
Er kann doch einfach den URL absaugen (LWP::UserAgent etc.)
nd den belauschten Header mit senden.Ja, dann hat er aber auch nur das PW in verschlüsselter Form (wird ja schließlich schon am Client verschlüsselt). Und den gleichen Header kann er auch nicht nehmen, weil die keine gültige SessionID enthält.
Bis später!
Peter
-
-
-
Hi Henk,
Jeder, der den verschlüsselten String "aus dem Netz fischt",
kann ihn auch weiterhin dazu benutzen, sich am Server anzumelden,
auch, wenn ihm Username und Passwort unbekannt sind...... wenn er weiß, wie er das machen muß.
Mit einem Browser geht das zunächst mal nicht. Dafür müßte er schon
ein eigenes Programm verwenden.Danach wäre ein solches login nicht sicherer als z.B. die Übertragung
des Usernamen und Passwortes im Klartext mit POST.Das natürlich schon (siehe oben).
Und auch die fehlende Rückübersetzung ist ein gewisser Schutz - vor
allem, wenn der Besitzer des Kennwortes dazu neigt, selbiges für
verschiedene Zwecke zu verwenden.Mache ich da irgendeinen Denkfehler?
Sobald ich einen client habe, der diesen HTTP-Header direkt senden
kann, gebe ich Dir erst mal recht.
Gegen Lauschangriffe helfen Passwörter mit eingebautem Verfallsdatum
sicherlich mehr.Viele Grüße
Michael-
Hallo Michael,
Mit einem Browser geht das zunächst mal nicht. Dafür müßte er schon
ein eigenes Programm verwenden.Wieso?
das untenstehende Formular würde doch dasselbe bewirken, wie das Formular in dem Feature-Artikel, damit wäre es also möglich, sich ohne Angabe von Passwort und Nutzernamen, nur mit Kenntnis des verschlüsselten Strings einzuloggen.
<form>
<input type="hidden" name="response" value="md5_verschluesselter_string"><input type="submit">
</form>Viele Grüße
Henk
-
Hi Henk,
das untenstehende Formular würde doch dasselbe bewirken, wie das
Formular in dem Feature-Artikel, damit wäre es also möglich, sich
ohne Angabe von Passwort und Nutzernamen, nur mit Kenntnis des
verschlüsselten Strings einzuloggen.Du beziehst Dich konkret auf diesen Feature-Artikel.
Ich beziehe mich auf MD5 allgemein - beispielsweise in der Form, wie
es bei "AuthType Digest" eingesetzt wird.
Da macht der Browser die Verschlüsselung selbst.Viele Grüße
Michael
-
-
-
Hallo,
Mache ich da irgendeinen Denkfehler?
Du hast vollkommen recht. Welchen String der Server nun vergleicht -
einen der nicht vorher MD5 verschluesselt wurde oder doch, ist voellig egal. Es bleibt immernoch ein einfacher Vergleich eines im Klartext ueber das Internet uebertragenen Strings. Der einzige Unterschied ist, dass Du ein anderes Passwort kennst, als der Server.
In meinen Augen absolut ueberfluessig. Also besser doch HTTPS ;-)Gruss, Thomas.