it-swarm.com.de

Ist die Verwendung von bcrypt für vorhandene SHA1-Hashes beim Umschalten der Kennwortimplementierung ausreichend?

Ich arbeite an der Verbesserung eines CMS, bei dem die aktuelle Implementierung zum Speichern des Passworts nur sha1(password) ist. Ich erklärte meinem Chef, dass es unglaublich unsicher sei, dies so zu tun, und sagte ihm, dass wir zu bcrypt wechseln sollten, und er stimmte zu.

Mein Plan war es, einfach alle vorhandenen Hashes über bcrypt auszuführen und diese im Passwortfeld zu speichern und dann das Passwort mit dem folgenden Psudo-Code zu überprüfen: correctPassword = bcrypt_verify(password, storedHash) or bcrypt_verify(sha1(password), storedHash).

Auf diese Weise erhalten neue Benutzer oder Benutzer, die ihre Kennwörter ändern, "echte" Verschlüsselungs-Hashes, während vorhandene Benutzer nicht alle ihre Kennwörter ändern müssen. Gibt es irgendwelche Nachteile dabei? Während es wahrscheinlich ideal wäre, alle Benutzer zu bitten, ein neues Passwort zu wählen, verlieren wir dadurch viel an Sicherheit?

Ich dachte, selbst wenn ein Angreifer Zugriff auf die Datenbank und den Code hat, wird das Knacken nicht wesentlich schneller sein, selbst wenn der Großteil der "Eingabe" für bcrypt eine 40-stellige Hex-Zeichenfolge ist, da der langsame Teil (bcrypt_verify()) muss weiterhin für jeden Passwortversuch für jeden Benutzer aufgerufen werden.

55
Alex

Tatsächlich ist dies ein guter Weg, um die ansonsten unsicher gespeicherten Passwörter zu schützen. Es gibt jedoch eine Schwachstelle in diesem Schema, die beim Markieren alter Hashes leicht überwunden werden kann. Daher würde ich diese Lösung vorziehen:

if (checkIfDoubleHash(storedHash))
  correctPassword = bcrypt_verify(sha1(password), storedHash)
else
  correctPassword = bcrypt_verify(password, storedHash)

Stellen Sie sich vor, ein Angreifer greift nach einem alten Backup. Er würde die SHA Hashes) sehen und könnte sie direkt als Passwörter verwenden, wenn Sie mit bcrypt_verify(...) or bcrypt_verify(sha1(...)) testen.

Die meisten bcrypt-Bibliotheken fügen selbst eine Markierung des verwendeten Algorithmus hinzu. Daher ist es kein Problem, wenn Sie eine eigene "doppelte Hash-Markierung" hinzufügen. Natürlich können Sie dafür auch ein separates Datenbankfeld verwenden:

$2y$10$nOUIs5kJ7naTuTFkBy1veuK0kSxUFXfuaOKdOKf9xYT0KKIGSJwFa
 |
 hash-algorithm = 2y = BCrypt
77
martinstoeckli

Warum nicht einfach bcrypt (sha1 (Passwort)) für alle alten und neuen Passwörter verwenden? Dies vermeidet das Problem, dass Benutzer Ihre alten Hashes als Kennwörter verwenden, und ist auch einfacher als Ihr Vorschlag.

8
Peter Green

Es ist eine gute Strategie, Sie verlieren keine Sicherheit, es sei denn, ein Benutzer hat beschlossen, ein wirklich zufälliges Passwort zu generieren, das länger als 160 Bit ist, da es abgeschnitten wird. Der Unterschied ist also minimal. (In diesem Fall würde es immer noch viel Zeit in Anspruch nehmen, den Originaltext zu erzwingen.)

Sie können sich dafür entscheiden, eine Logik zu implementieren, um die Kennwörter zu migrieren, wenn ein Benutzer sie das nächste Mal ändert. Ich sehe jedoch kein Risiko, das eine sofortige Änderung der Kennwörter erforderlich macht, es sei denn, Sie glauben, dass die Hashes durchgesickert sind.

4
Lucas Kauffman

Ich habe kürzlich ein ähnliches System für die Migration von Passwörtern zu bcrypt implementiert. Anstelle von SHA1 verwendeten wir jedoch ursprünglich SHA256-Hashes (Passwort + Salt).

Dieses Salz wird regeneriert, wenn wir den Benutzer beim Anmelden (optional) oder beim Ändern seines Passworts auf bcrypt umstellen. Der Hash würde also nicht auf dem Original basieren. Wir verwenden diese Nonce dann primär als IV, um den bcrypt-Hash in der Datenbank mit einem außerhalb der Datenbank gespeicherten Schlüssel zu verschlüsseln.

Dies verhindert nur wirklich Injektionsangriffe und Daten, die ausschließlich aus der Datenbank abgerufen werden und nützliche Kennwortinformationen liefern. Der Overhead war für uns jedoch kein Problem, und wir können diesen externen Schlüssel jederzeit ändern.

Wenn Sie den SHA256-Hash als Eingabe für bcrypt verwenden, bleibt die Länge des Eingabekennworts auch unter dem Maximum für bcrypt ( verwandtArtikel ).

Die einzige Sorge, die ich auch bei der Verwendung von SHA1 auf diese Weise sah, als ich mich nach Ratschlägen und Problemen mit allem umsah, was ich tat, war von Thomas Pornin im zweiten dieser beiden Links:

Die Verwendung einer sicheren Hash-Funktion zur Vorverarbeitung des Kennworts ist sicher. Es kann gezeigt werden, dass, wenn bcrypt (SHA-256 (Passwort)) fehlerhaft ist, entweder das Passwort erraten wurde oder ein Sicherheitsmerkmal von SHA-256 als falsch erwiesen wurde. Auf dieser Ebene besteht keine Notwendigkeit, mit dem Salz herumzuspielen. Hash das Passwort, dann benutze bcrypt für das Ergebnis (mit dem Salz, als bcrypt Mandate). SHA-256 wird als sichere Hash-Funktion angesehen.

Es ist also möglich, dass das Festhalten an SHA1 keine gute Wahl ist - warum sollte man sonst von der alleinigen Verwendung von SHA1 migrieren? Davon abgesehen ist es unwahrscheinlich, dass es eine Art Angriff gibt, der in naher Zukunft einen praktischen Wert für den Angriff auf eine Verschlüsselung (SHA1 (Passwort)) bietet, der keinen Kompromiss mit bcrypt selbst beinhaltet.

2
John Pettit