Passwortverschlüsselung

Diese Hashtabellen kann man auch schon für 50 bucks runterladen. http://passcracking.com machts möglich. MD5 ansich ist aber eh nicht sicher, es gibt Kollisionen im Quellcode (d.h. unterschiedliche Eingaben können gleiche Hashes ergeben. Technisch eigentlich unmöglich, aber erwiesen. Daran endete übrigens auch MD4) und bereits o.g. Tabellen mit Passwörtern von bis zu 8 Zeichen Länge. Was ist sicher? Wie wäre es mit OPT?

Wenn man bedenkt, dass eine beliebig lange Zeichenkette in einen 32 Zeichen langen Hash umgewandelt wird ist es eigentlich klar, dass Kollisionen auftreten. Dies ändert sich auch nicht mit SHA-1 oder 128 Bytes langen Schlüsseln, ansonsten hätte man schließlich die perfekte Kompressionstechnik gefunden.

Ein Vorteil von Hashes wie MD5 ist eben, dass man beliebig lange Passwörter verwenden kann die sich eben nicht entschlüsseln lassen. Im schlimmsten Fall kann ich, falls ich einen Hash "zurückrechne", ein mögliches Passwort haben und mich damit auf der Seite einloggen.

Ich führe da immer wieder gerne das Beispiel meiner Bank-PIN an:

Ohne MD5:
Ich benutze mein Passwort '4711' in einem Forum, es wird in der Datenbank gespeichert, die einem Cracker zum Opfer fällt. Dieser kann nun unter meinem Namen Beiträge verfassen und Geld von meinem Konto abheben.

Mit MD5 (der Einfachhalt halber verwende ich hier Quersumme() anstatt md5()):
Ich benutze mein Passwort '4711' in einem Forum, in der Datenbank wird der Hash Quersumme(4711), also 13, gespeichert. Ein Cracker bekommt die Datenbank in die Finger, rechnet den Hash zurück und kommt auf ein mögliches - aber eben nicht mein - Passwort: 8212. Damit kann er nun zwar in meinem Namen schreiben, allerdings kein Geld abheben.

In vielen Fällen kann er es doch. Da man sich beim einloggen per Cookie häufig mit Benutzer-ID und PW-Hash identifiziert, kann ich (falls der in der DB gespeicherte Hash identisch mit dem im Cookie gespeichertem Wert ist) den Hash den ich aus der Db geklaut habe in einen Cookie packen und mich so auf der Seite anmelden.

Eine potentielle Lösung über die ich mal gelesen habe wäre: Beim Login wird zweimal gehashed md5(md5($pass)) und dieser Wert auch in der Datenbank aufbewahrt, aber im Cookie wird nur der einfache Hashwert gespeichert. Dadurch kann man verhindern, dass ein aus der DB gestohlenes Passwort zum einloggen genutzt werden kann. (Es gibt auch andere Möglichkeiten: bspw. einen weiteren errechneten Prüfwert im Cookie zu speichern).

Das von dir genannte "salting" ist ein effektiver Schutz gegen vorberechnete Tabellen.
Aber es wird dir nicht helfen Replay-Attacken zu verhindern. Dafür müssten auf der Client-Seite Berechnungen angestellt werden können, was aber nicht immer möglich ist (JS aus, keine Plugins). Falls man dies doch voraussetzen will, wäre ein mögliches Verfahren bspw. das hier geschilderte: http://www.xml.com/pub/a/2003/12/17/dive.html


Genau das ist eines der Kriterien von Hashing: Es bildet eine große Menge von Elementen auf einen kleinere Menge von Elementen ab. Das Problem ist also nicht das Kollisionen auftreten. http://de.wikipedia.org/wiki/Hashing
Das Problem ist vielmehr, dass im August es jemand geschafft ein Verfahren zu entdecken mit dem man zwei Originalelemente finden kann die auf denselben Hash-Wert "abbilden" und (das ist das wichtige) mit deutlich weniger Aufwand als man eigentlich brauchen sollte. Allerdings ist dieses Verfahren selbst nicht publiziert worden (AFAIK). Und das wichtigste: Was sich nicht geändert hat, ist der Aufwand der notwendig ist um für einen Hash-Wert einen möglichen AUsgangswert zu finden.

Im Zusammenhang mit der hier vorgeschlagenen Verwendung (also: Vermeidung des Speicherns von Klartext-Passwörtern) braucht man also keine Bedenken haben (selbst wenn das entdeckte Verfahren publiziert wäre).

Danke für die ausführliche Erklärung! Hier scheint doch das fachkundigere Personal zu sitzen.

Also gut, für diesen Zweck wäre also das Salting ($salt . md5($salt . md5($passwort))) zum Generieren und Abspeichern des Hashes geeignet. Nun, Replay-Attacken lassen sich wohl kaum ausschließen (hab mir den Artikel noch nicht durchgelesen), wenn Cookie-Authentifizierung möglich sein soll, aber was speicher ich dann in dem Cookie ab? Nur den einfachen MD5 vom Passwort? Den könnte ich beim Login dann ja weiterverarbeiten. Ebenso müsste es funktionieren, wenn ich Tabellen mit Zugangsdaten übernehmen soll, die im einfachen MD5-Format vorliegen (Upgrade oder Import), richtig?

PS: Mir ist der Begriff "Keyed MD5" wieder eingefallen. Das wurde vor ner Weile schonmal irgendwo diskutiert. Hier ist die Präsentation dazu: http://www.research.ibm.com/security/keyed-md5.html

MD5 Verschlüsslung -> ein paar weitere Links ... auch nett der Service MD5 entschlüsseln zu lassen...