Salt bei Passwörtern: Wirkung und sichere Nutzung

Eine Hashfunktion bildet eine Eingabe auf einen Hashwert fester Länge ab. Beim Anmelden muss das System das Klartextpasswort nicht wiederherstellen: Es hasht die Eingabe erneut und vergleicht das Ergebnis mit dem gespeicherten Wert.

Ohne Salt liefert dasselbe Passwort bei demselben Verfahren denselben Hash. Ein Angreifer mit einer gestohlenen Datenbank könnte deshalb:

• gleiche Passwörter an gleichen Hashes erkennen;
• einen berechneten Passwortkandidaten gegen viele Konten gleichzeitig testen;
• vorberechnete Zuordnungen wie Rainbow Tables verwenden.

Ein individueller Salt verändert die Eingabe jedes Kontos. Eine Vorbereitung für einen Salt passt dann nicht zu einem anderen Salt.

Beim Anlegen oder Ändern eines Passworts läuft der Vorgang in dieser Reihenfolge ab:

1. Eine etablierte Bibliothek erzeugt einen kryptografisch zufälligen Salt.
2. Die Passwort-Hashfunktion verarbeitet Passwort, Salt und ihre Kostenparameter.
3. Das System speichert den resultierenden Hash zusammen mit Salt und Parametern.
4. Das Klartextpasswort wird nicht gespeichert.

Beim Login liest das System Salt und Parameter, verarbeitet die Eingabe auf dieselbe Weise und vergleicht den neu berechneten Hash mit dem gespeicherten Hash.

Moderne Bibliotheken speichern Salt und Parameter häufig in einem gemeinsamen Format. Ein bcrypt-Beispiel kann etwa Version, Kostenfaktor, Salt und Hash enthalten. Ein Kostenfaktor von 12 steht im dargestellten bcrypt-Schema für $2^{12}$, also 4096 Rechenschritte des zugrunde liegenden Kostenmodells. Das ist ein Formatbeispiel, keine für jedes System unveränderliche Parameterempfehlung.

Salt schützt vor allem gegen die Wiederverwendung von Vorberechnungen. Bei einem eigenen Salt pro Konto muss ein Angreifer jeden Passwortkandidaten für jedes Konto erneut berechnen.

Salt stoppt jedoch keinen Offline-Angriff auf einen einzelnen Hash. Wer Datenbank, Hash, Salt und Parameter besitzt, kann weiterhin Kandidaten ausprobieren. Der Salt ist schließlich nicht geheim.

Das unterscheidet sich vom Online-Angriff über ein Loginformular. Dort kann der Server Fehlversuche verzögern, begrenzen oder vorübergehend blockieren.

Für Passwörter sind deshalb eigens dafür entwickelte Verfahren wie Argon2id, scrypt oder bcrypt vorgesehen. Sie können Rechenzeit und teilweise Speicherbedarf gezielt erhöhen. Schnelle allgemeine Hashfunktionen wie MD5 oder die SHA-Familie sind allein für die Passwortspeicherung ungeeignet, weil ein Angreifer damit sehr viele Kandidaten schnell testen kann.

Eine sichere Passwortspeicherung verbindet mehrere Maßnahmen:

1. Individueller Salt: Jedes Passwort erhält einen eigenen zufälligen Wert.
2. Sicherer Zufall: Benutzername, Zeitstempel oder eine kleine feste Werteliste sind keine geeigneten Salts.
3. Passwort-Hashverfahren: Eine etablierte, absichtlich aufwendige Funktion verarbeitet Passwort und Salt.
4. Passende Kostenparameter: Der Aufwand wird für die vorhandene Serverleistung angemessen eingestellt und später überprüft.
5. Neue Berechnung bei Änderung: Bei einem Passwortwechsel wird auch ein neuer Salt erzeugt.
6. Bewährte Bibliothek: Erzeugung, Formatierung und Prüfung werden nicht selbst erfunden.

Diese drei Begriffe erfüllen unterschiedliche Aufgaben:

Ein Pepper ist ein zusätzliches Geheimnis, das in die Verarbeitung einfließt. Sein Nutzen hängt davon ab, dass er nicht gemeinsam mit der Passwortdatenbank gestohlen wird. Er ersetzt weder den individuellen Salt noch das langsame Passwort-Hashverfahren.

Passwort-Hashing ist nicht dasselbe wie Verschlüsselung. Verschlüsselung ist mit einem Schlüssel umkehrbar. Beim Passwort-Hashing ist diese Rückgewinnung nicht nötig: Das System prüft eine Eingabe durch erneutes Berechnen und Vergleichen.

Du kannst einen Speicherentwurf nun mit drei Fragen prüfen: Hat jedes Passwort einen eigenen zufälligen Salt? Nutzt das System ein geeignetes langsames Passwort-Hashverfahren? Werden zusätzliche Geheimnisse wie ein Pepper wirklich getrennt geschützt?