Hallo JanW2, > 1) Umsteigen auf ein modernes Hashverfahren, gerne. Funktioniert aber eigentlich nur auf folgendem Weg, oder? > Nutzer loggt sich ein. Ich prüfe ob das gehashte Passwort nach altem oder neuen (neue Spalte in der Nutzertabelle) Hashverfahren vorliegt. > Wenn Passworthash noch in der Spalte "alter Hash" vorliegt, dann authentifiziere ich den Nutzer nach dem alten Hashverfahren und bei gültigem Login hashe ich das eingegebe Klartextpasswort nach neuem Hashverfahren und speichere es dann in der Spalte "neuer Hash" ab. Das ist ein mögliches Verfahren, ja. Ich würde allerdings lieber eine Spalte „Hash-Version“ einfügen und bei veraltetem Hash-Verfahren die Spalte mit dem Passwort-Hash sowie die Versions-Spalte upzudaten. So hast du die Möglichkeit später das Hash-Verfahren ohne Änderung am Mechanismus und Datenmodell erneut zu ändern. > Den alten Hash kann ich dann ja prinzipiell löschen. Den kannst du nicht nur prinzipiell löschen, den solltest du **unbedingt** löschen bzw überschreiben. > Zu deinem > > es ist nicht mehr möglich, eine Rainbow Table voraus zu berechnen. > > Ist es nicht egal, ob die Rainbow Table vorausberechnet wird? Wenn ein Angreifer eh die Daten hat, dann kann er das Klartext-Salt ja dazu verwenden, einfach eine neue Rainbow-Tabelle zu berechnen? Klar, aber das kostet Plattenplatz und dauert Zeit. Und er muss das bei jedem Passwort neu machen, denn der Hash ist ja bei jedem Passwort anders. Dadurch werden Brute-Force-Angriffe über Rainbow-Tables einfach unattraktiv weil zu teuer. Da nutzt man dann lieber Wörterbuch-Attacken oder sowas. LG, CK -- <https://wwwtech.de/about>

Hallo JanW2, > 1) Umsteigen auf ein modernes Hashverfahren, gerne. Funktioniert aber eigentlich nur auf folgendem Weg, oder? > Nutzer loggt sich ein. Ich prüfe ob das gehashte Passwort nach altem oder neuen (neue Spalte in der Nutzertabelle) Hashverfahren vorliegt. > Wenn Passworthash noch in der Spalte "alter Hash" vorliegt, dann authentifiziere ich den Nutzer nach dem alten Hashverfahren und bei gültigem Login hashe ich das eingegebe Klartextpasswort nach neuem Hashverfahren und speichere es dann in der Spalte "neuer Hash" ab. Das ist ein mögliches Verfahren, ja. Ich würde allerdings lieber eine Spalte „Hash-Version“ einfügen und bei veraltetem Hash-Verfahren die Spalte mit dem Passwort-Hash sowie die Versions-Spate upzudaten. So hast du die Möglichkeit später das Hash-Verfahren ohne Änderung am Mechanismus und Datenmodell erneut zu ändern. > Den alten Hash kann ich dann ja prinzipiell löschen. Den kannst du nicht nur prinzipiell löschen, den solltest du **unbedingt** löschen bzw überschreiben. > Zu deinem > > es ist nicht mehr möglich, eine Rainbow Table voraus zu berechnen. > > Ist es nicht egal, ob die Rainbow Table vorausberechnet wird? Wenn ein Angreifer eh die Daten hat, dann kann er das Klartext-Salt ja dazu verwenden, einfach eine neue Rainbow-Tabelle zu berechnen? Klar, aber das kostet Plattenplatz und dauert Zeit. Und er muss das bei jedem Passwort neu machen, denn der Hash ist ja bei jedem Passwort anders. Dadurch werden Brute-Force-Angriffe über Rainbow-Tables einfach unattraktiv weil zu teuer. Da nutzt man dann lieber Wörterbuch-Attacken oder sowas. LG, CK -- <https://wwwtech.de/about>