Hallo Christian, > > > > Einerseits musst du dafür eine Passwort-Historie speichern (sehr schlecht), und andererseits geht dich das nichts an. > > > > > > Ist eine Historie der gehashten und gesalzten Passwörter immer noch "sehr schlecht"? > > > > Und es könnte sogar sein, dass verschiedene Passwörter denselben Hash haben. Das wird umso wahrscheinlicher je mehr die Passwörter zufällig sind. > > Nein, das ist aufgrund der modernen Hashing-Algorithmen de facto ausgeschlossen. Mir ist nicht klar, warum man das anders sehen sollte. Bei bcrypt (Default-Verfahren für `password_hash`) wird ein 192-bit-Hash erzeugt, dessen Key abgeleitet wird von dem Passwort. Das ist kein traditionelles Salting/Hashing mehr. Der Key (man könnte ihn auch Salt nennen) ist 128 bit lang. Die Wahrscheinlichkeit, eine Kollision zu erzeugen, also τ1,τ2=bcrypt(pw,cost), Pr[τ1=τ2] liegt also bei $$2^{64}$$ - eine Kollision innerhalb der Passwort-Historie ist de facto ausgeschlossen. **Edit:** nicht die Wahrscheinlichkeit ist bei $$2^{64}$$, sondern man erhält durchschnittlich bei $$2^{64}$$ Hashing-Vorgängen eine Kollision. **Edit 2:** Der `cost`-Parameter kommt aus dem bcrypt-Algorithmus, der vorsieht, dass ein Passwort nicht nur einmal diesen Algorithmus durchläuft, sondern n mal, um Sidechannel-Attacken vorzubeugen. LG, CK -- <https://wwwtech.de/about>

Hallo Christian, > > > > Einerseits musst du dafür eine Passwort-Historie speichern (sehr schlecht), und andererseits geht dich das nichts an. > > > > > > Ist eine Historie der gehashten und gesalzten Passwörter immer noch "sehr schlecht"? > > > > Und es könnte sogar sein, dass verschiedene Passwörter denselben Hash haben. Das wird umso wahrscheinlicher je mehr die Passwörter zufällig sind. > > Nein, das ist aufgrund der modernen Hashing-Algorithmen de facto ausgeschlossen. Mir ist nicht klar, warum man das anders sehen sollte. Bei bcrypt (Default-Verfahren für `password_hash`) wird ein 192-bit-Hash erzeugt, dessen Key abgeleitet wird von dem Passwort. Das ist kein traditionelles Salting/Hashing mehr. Der Key (man könnte ihn auch Salt nennen) ist 128 bit lang. Die Wahrscheinlichkeit, eine Kollision zu erzeugen, also τ1,τ2=bcrypt(pw,cost), Pr[τ1=τ2] liegt also bei $$2^{64}$$ - eine Kollision innerhalb der Passwort-Historie ist de facto ausgeschlossen. **Edit:** nicht die Wahrscheinlichkeit ist bei $$2^{64}$$, sondern man erhält durchschnittlich bei $$2^{64}$$ Hashing-Vorgängen eine Kollision. LG, CK -- <https://wwwtech.de/about>

Hallo Christian, > > > > Einerseits musst du dafür eine Passwort-Historie speichern (sehr schlecht), und andererseits geht dich das nichts an. > > > > > > Ist eine Historie der gehashten und gesalzten Passwörter immer noch "sehr schlecht"? > > > > Und es könnte sogar sein, dass verschiedene Passwörter denselben Hash haben. Das wird umso wahrscheinlicher je mehr die Passwörter zufällig sind. > > Nein, das ist aufgrund der modernen Hashing-Algorithmen de facto ausgeschlossen. Mir ist nicht klar, warum man das anders sehen sollte. Bei bcrypt (Default-Verfahren für `password_hash`) wird ein 192-bit-Hash erzeugt, dessen Key abgeleitet wird von dem Passwort. Das ist kein traditionelles Salting/Hashing mehr. Der Key (man könnte ihn auch Salt nennen) ist 128 bit lang. Die Wahrscheinlichkeit, eine Kollision zu erzeugen, also τ1,τ2=bcrypt(pw,cost), Pr[τ1=τ2] liegt also bei $$2^{64}$$ - eine Kollision innerhalb der Passwort-Historie ist de facto ausgeschlossen. LG, CK -- <https://wwwtech.de/about>