Passwort-Hashing: Salt, Algorithmen und Login

Eine Hashfunktion bildet eine Eingabe auf einen Hashwert fester Länge ab. Für die Passwortspeicherung soll aus dem Hash das ursprüngliche Passwort praktisch nicht zurückgewonnen werden können.

Hashing und Verschlüsselung erfüllen unterschiedliche Aufgaben:

• Verschlüsselung ist umkehrbar: Mit dem passenden Schlüssel lassen sich die Daten wiederherstellen.
• Hashing ist nicht zur Wiederherstellung gedacht: Eine neue Eingabe wird verarbeitet und mit dem gespeicherten Ergebnis verglichen.

Dass ein Hash nicht entschlüsselt wird, bedeutet nicht, dass das Passwort unangreifbar ist. Nach einem Datenbankdiebstahl können Angreifer Kandidaten hashen und nach einer Übereinstimmung suchen. Das ist ein Offline-Angriff, weil dafür keine weiteren Anfragen an den Anmeldeserver nötig sind.

Ohne Zusatzwert erzeugen identische Passwörter beim gleichen Verfahren identische Hashes. Ein Datenbankleck würde dadurch sofort zeigen, welche Konten vermutlich dasselbe Passwort verwenden.

Der Salt muss nicht geheim sein. Seine Aufgabe ist die Einzigartigkeit: Selbst wenn zwei Personen dasselbe Passwort wählen, führen unterschiedliche Salts zu unterschiedlichen gespeicherten Hashes.

Vorberechnete Tabellen mit bekannten Passwort-Hash-Paaren werden dadurch weitgehend unbrauchbar. Angreifer müssen jeden Kandidaten für jeden Salt neu berechnen.

Allgemeine Hashfunktionen wie MD5, SHA-1 oder SHA-256 sind auf schnelle Berechnungen ausgelegt. Genau diese Geschwindigkeit ist bei Passwörtern ein Nachteil: Angreifer können sehr viele Kandidaten in kurzer Zeit testen. MD5 und SHA-1 sind zudem kryptografisch gebrochen und für Passwortspeicherung ungeeignet.

Passwort-Hashfunktionen wie bcrypt, scrypt und Argon2 wurden für diesen Zweck entwickelt. Sie erhöhen den Rechenaufwand; scrypt und Argon2 können zusätzlich viel Speicher beanspruchen. Das verteuert besonders massenhaft parallele Versuche mit Spezialhardware.

Die Einstellung muss zwei Ziele ausgleichen:

• Ein legitimer Login soll noch in angemessener Zeit möglich sein.
• Massenhaftes Ausprobieren soll möglichst teuer werden.

Mit steigender Rechenleistung sollte der Betreiber die Parameter prüfen und bei Bedarf anheben. Salt und Work Factor erfüllen dabei verschiedene Aufgaben: Der Salt verhindert wiederverwendbare Vorberechnungen, der Work Factor verteuert jede neue Berechnung.

Bei einer sicheren Registrierung läuft die Speicherung so ab:

1. Die Anwendung erhält das Passwort nur für die aktuelle Verarbeitung.
2. Sie erzeugt einen neuen zufälligen Salt.
3. Sie verarbeitet Passwort und Salt mit einer geeigneten Passwort-Hashfunktion und festgelegten Kostenparametern.
4. Sie speichert Hash, Salt, Algorithmus beziehungsweise Format und Parameter.
5. Das Klartextpasswort wird nicht gespeichert.

Beim Login folgt die Anwendung diesem Ablauf:

1. Sie liest die gespeicherten Hashdaten des Kontos.
2. Sie verarbeitet die eingegebene Zeichenfolge mit demselben Salt, Verfahren und denselben Parametern.
3. Sie vergleicht den neu berechneten Hash mit dem gespeicherten Hash.
4. Nur bei Übereinstimmung ist die Passwortprüfung erfolgreich.

Passwort-Hashing begrenzt den Schaden eines Datenbanklecks, löst aber nicht jedes Sicherheitsproblem.

• Bei einem Wörterbuchangriff probieren Angreifer häufige Wörter und bekannte Passwörter aus.
• Beim Brute-Force-Angriff werden systematisch viele mögliche Zeichenfolgen getestet.
• Beim Credential Stuffing werden gestohlene Zugangsdaten bei anderen Diensten ausprobiert.
• Beim Password Spraying wird ein häufiges Passwort gegen viele Konten getestet.

Schwache oder wiederverwendete Passwörter bleiben daher gefährlich. Salt und Work Factor bremsen Angriffe, ersetzen aber keine starken, einzigartigen Passwörter.

Typische Entwurfsfehler sind:

• Klartextpasswörter speichern;
• denselben Salt für viele Konten verwenden;
• MD5, SHA-1 oder eine schnelle allgemeine Hashfunktion allein einsetzen;
• Kostenparameter dauerhaft unverändert lassen;
• glauben, Hashing schütze auch während Eingabe und Übertragung;
• Passwort-Hashing mit Transportverschlüsselung verwechseln.

Bestehende Systeme können alte Hashes nicht einfach in neue Hashes umrechnen, denn das ursprüngliche Passwort ist nicht bekannt. Eine schrittweise Migration nutzt deshalb den nächsten erfolgreichen Login:

1. Das System erkennt am gespeicherten Format, welches alte Verfahren verwendet wurde.
2. Es prüft die Anmeldung noch einmal mit diesem Verfahren.
3. Nach erfolgreicher Prüfung liegt das eingegebene Passwort kurzfristig vor.
4. Das System erzeugt einen neuen Salt und hasht das Passwort mit dem modernen Verfahren.
5. Es ersetzt die alten Hashdaten durch die neuen Angaben.

Konten ohne erfolgreichen Login können über einen Passwort-Reset umgestellt werden. Während der Übergangszeit muss das System die Formate eindeutig unterscheiden und die alte Methode nur so lange wie nötig unterstützen.

Prüfe deinen Entwurf abschließend mit vier Fragen:

1. Wird irgendwo ein Klartextpasswort dauerhaft gespeichert oder wiederherstellbar abgelegt?
2. Erhält jedes neue Passwort einen eigenen zufälligen Salt?
3. Wird eine geeignete Passwort-Hashfunktion mit dokumentierten, anpassbaren Parametern verwendet?
4. Kann das System alte Hashformate erkennen und kontrolliert auf das neue Verfahren migrieren?