Crypto agility: Umstellen der Passwort-Hashfunktion in einem bestehen System

Only in German available.

Bei den Hash-Algorithmen, welche es erlauben, Passwörter sicher abzuspeichern, gibt es laufend Verbesserungen. Aktuell ist die Empfehlung von OWASP Argon2id als Hashfunktion zu verwenden (https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html). Früher war es bcrypt. Nun gibt es die Herausforderung, wie man in einem bestehenden System die Passwörter neu hasht und speichert. Dazu gibt es drei Möglichkeiten:

1. Passwort reset forcieren
2. Update beim nächsten User-Login
3. new_hash(old_hash(pw)): Die verschiedenen Algorithmen zusammenzuhängen

Schauen wir uns die Vor- und Nachteile der einzelnen Varianten an.

1. Passwort reset forcieren

Alle Benutzer des Systems werden aufgefordert, ihr Passwort neu zu setzen. Die bestehenden alten Passwort-Hashes werden gelöscht.

Vorteile:

• Umstellung zu einem definierten Zeitpunkt möglich
• Keine alten Hashes in der Datenbank

Nachteile:

• Unbequem für den Benutzer
• Verunsicherung der Benutzer: Weshalb muss ich jetzt hier mein Passwort neu setzen?
• Vertrauensverlust der Benutzer: Gab es einen Cyberangriff, dass ich das jetzt machen muss?

2. Update beim nächsten User-Login

Bei einem Login wird das Passwort mit der alten Hashfunktion geprüft und anschliessend mit der neuen Hashfunktion gehasht und abgespeichert.

Vorteile:

• Benutzer merkt nichts von der Umstellung

Nachteile:

• Neue und alte Hashfunktion müssen unterstützt werden
• Alte Hashes bleiben lange in der Datenbank gespeichert, wenn sich ein Benutzer nie neu einloggt; Risiko bei einem Databreach alte Hashwerte zu verlieren ist höher

3. new_hash(old_hash(pw)): Die verschiedenen Algorithmen zusammenzuhängen

Die alten Hashwerte dienen als Input für die neue Hashfunktion.

Vorteile:

• Benutzer merkt nichts von der Umstellung
• Es gibt keine alten Hashwerte mehr in der Datenbank

Nachteile:

• Neue und alte Hashfunktion müssen unterstützt werden
• Anfällig für Passwort Shucking* Angriffe (siehe Youtube: DEF CON Safe Mode: Password Village - Sam Croley: What the Shuck? Layered Hash Shucking)

Empfehlung: Variante 3 mit Anpassungen.

Anpassung 1: Einen Pepper verwenden Anstatt new_hash(old_hash(pw)) sollte man new_hash(old_hash(pw)+pepper) verwenden. Diesen Pepper nicht in der Datenbank abspeichern. Wird die Datenbank erbeutet, so ist der Pepper immer noch unbekannt. Dies schützt gegen Passwortshucking.

Anpassung 2: Bei einem Login new_hash(old_hash(pw)+pepper) in new_hash(pw) reduzieren, so kann man die alte Hashfunktion loswerden. Bei Benutzer, welche sich lange nicht einloggen, wird trotzdem die neue starke Hashfunktion verwendet.

*Password-Shucking

Angriff auf ein Passwort, welches durch mehrere Layer (new_hash(old_hash(pw))) gehasht wurde. Dabei wird nicht die neue starke Hashfunktion (new_hash()) angegriffen, sondern die ältere schwächere Hashfunktion (old_hash()). Anfällig sind Benutzer, welche in einem anderen Databreach auftauchen, welche die ältere schwächere Hashfunktion verwenden und das gleiche Passwort mehrfach verwenden.