Menu:

apology

(de only, sorry...)

Immer und immer wieder wird das JS-MD5-Login Verfahren in Frage gestellt.

Natürlich ist es richtig, nur https bietet die sicherste Lösung. Allerdings sollten man auch wissen: Unsignierte dummy-Zertifikate, die ohne Zertifizierungsverfahren selbst erstellt wurden, sind verwundbar für einen Man-In-The-Middle-Angriff.

Jedoch ist es nun einmal so, das man nicht immer secure http zur Verfügung hat. Was also tun? Es so machen wie alle anderen und Passwörter dann einfach im Klartext durch das Internet schicken???

Ich bin der Meinung es ist besser etwas für die Sicherheit zu tun als überhaupt nichts!

Wenn Passwörter im Klartext durchs Internet wandern, braucht nur jemand diese zu einzufangen und mal probieren, ob diese nicht evtl. auch bei eBay, Amazon und Co. funktionieren. Aber natürlich benutzt jeder für jeden Dienst ein anderes Passwort, na sicher.

Natürlich funktioniert das ganze leider nur mit JavaScript. Ohne geht es einfach nicht. Wie soll man sonst auf dem Client das Klartextpasswort verarbeitet können? Dies ist allerdings zwingend notwendig.
Es gibt (bisher nur in der SVN Version) ein "Fallback" für den Fall das JS wirklich nicht verfügbar ist. Der User sieht dann ein Link zu einem Non-JS-unsecure-Login ;)

Klar ist: Das JS-MD5-Login Verfahren verhindert es, das ein Passwort in Klartext übermittelt wird. Es ist auch nicht so, das einfach nur eine MD5 Hash vom Passwort übermittelt wird. Das gesamte Verfahren ist ein wenig Komplizierter. Der PseudoCode zeigt das allerdings recht einfach.

Es ist sichergestellt, das ein Angreifer mit den Übermittelten Login Daten nicht auf das Passwort Rückschließen kann. Außerdem ist sichergestellt, das die auf dem Server hinterlegten Daten nicht einfach für einen Login genutzt werden können. Es bietet ebenfalls keinen direkten Rückschluss auf das User-Passwort. Somit hat ein SQL-Dump, in den Fingern eines bösen Buden, auch nicht viel Wert!

Und zum Schluss: Eine Absolute Sicherheit gibt es wohl nicht und wird es wohl auch nie geben ;)