Viele System hashen ihre Passwörter immer noch einfach mit MD5. MD5 ist seit längerer Zeit nicht mehr wirklich sicher und ohne Salt sollte man heute sowie so nicht mehr arbeiten. Eines der großen Probleme von MD5 ist, dass es sehr schnell ist. Wenn man Checksums für Dateien erstellen möchte ist es ideal, aber gerade bei Brute-force Angriffen ist ein langsamer Hash-Algorithmus von Vorteil, weil er die Zeit und damit den Aufwand extrem in die Höhe treibt. Salts tun das selbe für Wörterbuch Attacken und Rainbow-Tables.

Wenn man nun auf etwas sicheres Wechseln möchte ist es gar nicht so schwer. Man muss nicht die Passwörter der Benutzer vorliegen haben. Denn bei jedem Login liegt das Passwort für kurze Zeit in der Login-Methode sowie so als Klartext vor. Hier ist also der beste Punkt, um die Änderungen vorzunehmen. Es gibt nur eines dabei zu beachten.

Am Besten fügt man der User Entity ein Version-Flag hinzu, dass man verwendet um festzuhalten welche Hash-Variante gerade verwendet wird. 0 wäre dann einfaches MD5. Es sollte Integer sein, weil boolean einfach zu wenig ist und es mit der Zeit mehr als zwei Möglichkeiten für das Passwort geben wird... ich muss nochmal umbauen.
Wenn der Benutzer sich also einloggt und das Flag auf 0 steht, bedeutet es, dass man den Passwort-Eintrag in der Datenbank aktualisieren muss. Der Login muss dann eben alle möglichen Kombinationen aus Version Flag und Hash-Methode unterstützen. Flag und Hash-Methode immer zusammen, um alles noch sicher zu halten.. ob es ohne wirklich unsicher wäre, müsste man noch mal durch denken, aber verkehr es abzugleichen ist es sicher nicht.

Nun haben wir schon mal unseren neuen Hash, der gesetzt wird, sobald sich der Benutzer das nächste mal einloggt. Jetzt fehlt der Hash und dazu ist nicht viel zu sagen.



NUR niemals den Benutzernamen als Salt verwenden! Denn das würde bedeuten, dass man bei einer Änderung des Benutzernamen auch immer den Passwort-Hash neu setzen müsste und wenn der Admin den Namen des Benutzers ändert, hat er das einfach nicht. Das Salt kann ein Zufallscode sein und mit in der Entity gespeichert werden, würde der Name ja auch und es geht ja nur darum das Berechnen der Hashes aufwendiger zu machen und nicht Security through obscurity zu betreiben. Hier muss ich auch noch mal nacharbeiten :-)