Beim Salting erhält jedes Passwort vor der Passwort-Hashfunktion einen eigenen zufälligen Zusatzwert, den Salt. Dadurch erzeugen zwei gleiche Passwörter unterschiedliche gespeicherte Hashes. Der Salt ist kein zweites Passwort und muss normalerweise nicht geheim sein; er wird zusammen mit Hash, Algorithmus und Parametern gespeichert.
Wie funktioniert Salting?
- Bei der Passwortvergabe erzeugt die Anwendung mit einem kryptografisch sicheren Zufallsgenerator einen neuen Salt.
- Eine dafür geeignete Passwort-Hashfunktion verarbeitet Passwort, Salt und Kostenparameter.
- Gespeichert werden Ergebnis, Salt und die zur Verifikation erforderlichen Parameter – niemals das Klartextpasswort.
- Beim Login berechnet die Anwendung mit dem gespeicherten Salt erneut den Hash und vergleicht ihn zeitkonstant.
- Nach erfolgreichem Login kann sie veraltete Parameter erkennen und den Hash mit stärkeren Einstellungen erneuern.
Moderne Bibliotheken für Argon2id, scrypt, bcrypt oder PBKDF2 erzeugen und kodieren den Salt üblicherweise selbst. Eigenes Zusammenkleben von Zeichenketten und Hashes ist unnötig und fehleranfällig.
Wogegen schützt ein Salt?
| Ohne individuellen Salt | Mit individuellem Salt |
|---|---|
| Gleiche Passwörter haben gleiche Hashes und werden sofort als gleich erkannt. | Jeder Datensatz besitzt einen anderen Hash. |
| Vorberechnete Rainbow Tables lassen sich gegen viele Datenbanken wiederverwenden. | Vorberechnung muss für jeden Salt erneut erfolgen und wird unpraktisch. |
| Ein Rateversuch kann gleichzeitig gegen alle Nutzer geprüft werden. | Der Angreifer berechnet Kandidaten für jeden Nutzer separat. |
Ein Salt verhindert kein Raten schwacher Passwörter nach einem Datenbankdiebstahl. Kennt der Angreifer Salt und Hash, kann er Kandidaten offline prüfen. Dagegen hilft vor allem eine absichtlich langsame, speicherintensive Passwort-Hashfunktion mit angemessenen Parametern und starke Passwörter.
Was unterscheidet Salt und Pepper?
Ein Salt ist pro Passwort verschieden, öffentlich speicherbar und schützt gegen Wiederverwendung vorberechneter Arbeit. Ein Pepper ist ein zusätzliches geheimes Element, das getrennt von der Passwortdatenbank – etwa in einem Secret-Management oder HSM – verwahrt wird. Ein Pepper kann einen reinen Datenbankdiebstahl erschweren, bringt aber Schlüsselrotation, Verfügbarkeit und Wiederherstellung als Betriebsaufgaben mit. Er ersetzt weder Salt noch geeignete Hashfunktion.
Wie werden Passwörter richtig gespeichert?
- Eine etablierte Bibliothek mit Argon2id verwenden; scrypt, bcrypt oder PBKDF2 können je nach Plattform und Anforderungen geeignete Alternativen sein.
- Zeit-, Speicher- und Parallelitätskosten anhand eigener Systeme so hoch wählen, dass Login vertretbar bleibt und Offline-Raten teuer wird.
- Für jeden Passwortwechsel einen neuen ausreichend zufälligen Salt erzeugen.
- Hashformat und Versionierung so speichern, dass Parameter später schrittweise angehoben werden können.
- Login-Endpunkte zusätzlich mit Rate Limiting und MFA schützen und kompromittierte Passwörter ablehnen.
Welche Fehler sind häufig?
Ein globaler Salt für alle Nutzer beseitigt einen wesentlichen Vorteil. Benutzername, E-Mail oder Zeitstempel sind vorhersagbar und kein guter zufälliger Salt. Schnelle allgemeine Hashfunktionen wie SHA-256 oder MD5 bleiben auch mit Salt für Passwortspeicherung ungeeignet. Verschlüsselung ist ebenfalls kein Ersatz: Wird ihr Schlüssel gestohlen, sind alle Passwörter direkt entschlüsselbar. Passwörter sollten verifiziert, nicht zurückgewonnen werden.
Vielen Dank für dein Feedback! Wir werden es prüfen und unseren Artikel anpassen.