Was ist Salting in der IT-Sicherheit? Passwort-Hashing erklärt

Im Juni 2012 veröffentlichte ein Angreifer 117 Millionen LinkedIn-Konten in einem russischen Forum. Die Liste bestand aus einer ungefilterten Sammlung ungesalzener SHA-1-Hashes. SHA-1 ist sehr schnell. Da kein Salt verwendet wurde, um identische Passwörter zu unterscheiden, stand derselbe Hash tausendfach neben demselben. Innerhalb von etwa 72 Stunden hatten Sicherheitsforscher rund 90 Prozent der Datei entschlüsselt. Als der Datenverstoß im Mai 2016 im Rahmen eines Datensatzes mit 167 Millionen Einträgen erneut auftauchte, wurden diese Zugangsdaten jahrelang für Credential-Stuffing-Angriffe missbraucht.

Die Verteidigungsmethode, die diesen Datenverstoß zu einer Randnotiz gemacht hätte – nämlich jedem gespeicherten Passwort ein Salt hinzuzufügen –, existierte bereits 1979. Sie nennt sich Salting. Sie ist weder neu noch teuer und auch nicht besonders raffiniert. Sie ist der entscheidende Unterschied zwischen einem Datenbankleck, das sich in Grenzen hält, und einem Passwortproblem, das ein halbes Jahrzehnt lang alle beschäftigt.

Die meisten Sicherheitslücken bei modernen Passwortspeichern haben immer noch dieselbe Ursache: Jemand hat entschieden, dass „SHA-256“ ausreichend sei. Dieser Artikel erklärt, was Salting genau ist, wie es in der Praxis funktioniert, wovor es schützt und wovor nicht, und welchen Standard OWASP für 2026 empfiehlt.

Was ist Salting in der Sicherheit und beim Passwort-Hashing?

Fassen wir das Thema in einem Satz zusammen: Salting bedeutet, einem Passwort vor dem Hashing zufällige Daten hinzuzufügen. Dieser Zufallswert – das Salt – wird einmal pro Konto zusammen mit dem neuen Passwort-Hash generiert, unverschlüsselt neben dem Hash gespeichert und bei jedem Login wieder ausgelesen. Es handelt sich dabei weder um einen Schlüssel noch um ein Geheimnis oder eine Verschlüsselung. Es ist ein öffentlicher Parameter mit genau einer Aufgabe: sicherzustellen, dass zwei Benutzer mit demselben Passwort niemals denselben gespeicherten Hash verwenden.

Hashing allein ist eine Einwegoperation. Wird ein Passwort durch SHA-256 oder Argon2id geleitet, erhält man einen Wert fester Länge, den kein Algorithmus umkehren kann. Der Haken dabei ist, dass „kein Algorithmus“ eine einfache Abkürzung ausschließt: das Nachschlagen des Hashwerts in einem vorab berechneten Wörterbuch. Salting verhindert diese Abkürzung. Durch das Hinzufügen eines Salts zum Hashing-Prozess wird für jeden Benutzer ein eindeutiger Hashwert erzeugt, selbst wenn das zugrundeliegende Passwort wortwörtlich identisch ist. Häufige Passwörter wie „password“ und „qwerty“ kollidieren nicht mehr in der Datenbank. Salting stellt sicher, dass das Auslesen einer einzigen Zeile dem Angreifer keinerlei Informationen über andere Benutzer liefert.

Drei Regeln unterscheiden ein brauchbares Salt von einem nutzlosen. Erste Regel: Jedes Passwort erhält ein eigenes, zufällig generiertes Salt, das bei der Registrierung oder beim Zurücksetzen des Passworts neu erstellt wird. Ein gesalzenes Passwort, das für mehrere Konten wiederverwendet wird, ist kaum besser als ein ungesalzenes – Massenangriffe funktionieren auf dieselbe Weise. Zweite Regel: Das Salt darf öffentlich sein. Kennt man nur das Salt, bietet es einem Angreifer keinerlei Abkürzung gegen die zugrundeliegende Hash-Funktion. Daher befindet sich das Salt in der Datenbank neben dem Hash, und diese Platzierung ist zulässig, ja sogar empfehlenswert. Dritte Regel: Die Salt-Werte stammen von einem kryptografisch sicheren Pseudozufallszahlengenerator. Linux stellt einen solchen über `getrandom(2)` bereit. Node.js nennt ihn `crypto.randomBytes`. Die Python-Standardbibliothek kapselt ihn in `secrets.token_bytes`. Die nicht-kryptografische Funktion `Math.random()` ist ungeeignet, obwohl sie in geprüftem Quellcode viel häufiger vorkommt, als sie sollte.

Zwei Personen, die „hunter2“ als Passwort wählen, erhalten zwei völlig unterschiedliche gespeicherte Hashes. Das liegt am Salting. Ohne Salt gibt die Datenbank nicht nur Hashes preis, sondern auch das soziale Netzwerk, das zeigt, wer welches Passwort mit wem teilt.

Wie funktioniert Passwort-Salting?

Der Mechanismus lässt sich in vier Schritte unterteilen, und zehn Jahre an Passwort-Speicherlecks zeigen, dass fast jeder Fehler darauf zurückzuführen ist, dass jemand einen dieser Schritte übersprungen hat.

Schritt eins wird bei der Registrierung ausgeführt. Die Anwendung fordert von einem kryptografisch sicheren Pseudozufallszahlengenerator (CSPRNG) 16 bis 32 zufällige Bytes an. Dies ist das Salt. Die OWASP-Richtlinien von 2025 legen 16 Bytes (128 Bit) als Mindestgröße fest; auth0 und diverse Passwortmanager empfehlen 32 Bytes. NIST SP 800-63B-4 definiert ein Minimum von vier Bytes, warnt jedoch davor, dass bei dieser Größe ab etwa 65.000 Benutzern Kollisionen aufgrund von Geburtsdatumswerten auftreten. Aus diesem Grund verwendet praktisch niemand vier Bytes.

Im zweiten Schritt wird das Salt mit dem vom Benutzer gewählten Passwort kombiniert. Die gängigste Methode ist die Verkettung, bei der das Salt vor oder nach der Passwortzeichenkette steht. Einige Systeme verwenden stattdessen HMAC und behandeln das Salt als HMAC-Schlüssel. Dadurch werden einige schwer zu erkennende Probleme mit der Längenerweiterung bei der reinen Verkettung umgangen.

Im dritten Schritt wird die kombinierte Eingabe durch einen Passwort-Hashing-Algorithmus geleitet – in Lehrbüchern der Kryptografie als Schlüsselableitungsfunktion (KDF) bezeichnet. An diesem Punkt scheiterten die meisten Teams früher, indem sie oft zu einem generischen Hash-Algorithmus griffen und dachten, die Aufgabe sei erledigt. Einfaches SHA-256 ist allein ungeeignet, um Passwörter zu speichern. Eine handelsübliche GPU berechnet im Jahr 2026 über hundert Milliarden SHA-256-Hashes pro Sekunde, sodass die Kosten pro Versuch beim kryptografischen Hashing selbst mit einem Salt vernachlässigbar bleiben. Salting verhindert Rainbow-Table-Angriffe. Es verlangsamt jedoch nicht das Knacken von Passwörtern per Brute-Force. Das richtige Werkzeug ist hier eine bewusst langsame, speicherintensive Funktion: Argon2id ist der von OWASP empfohlene Standard, scrypt und bcrypt sind akzeptabel, und PBKDF2 mit sehr hohen Iterationszahlen ist zulässig, wenn die FIPS-140-Konformität dies erfordert.

Schritt vier speichert sowohl den Hash als auch das Salt. Moderne Bibliotheken verwalten das Speicherformat, sodass Sie das gespeicherte Salt nicht manuell verwalten müssen. Die Ausgabe von bcrypt sieht beispielsweise so aus: `$2b$12$9f4c8a7b...kQR8YZpL9` – diese einzelne Zeichenkette enthält die Algorithmus-Kennung, den Kostenfaktor, das Salt und den Hashwert. Argon2id verwendet das analoge PHC-Zeichenkettenformat: `$argon2id$v=19$m=19456,t=2,p=1$$`. Sie schreiben diese Zeichenkette in eine Datenbankspalte und können sich dann anderen Dingen widmen. Die Bibliothek hat alles Notwendige für die sichere Speicherung von Passwörtern erledigt: Sie generierte Zufallsdaten für das Salt, berechnete das Passwort mithilfe eines langsamen Hash-Algorithmus und bündelte das Ergebnis für den Abruf.

Der Login-Prozess folgt dem gleichen Ablauf, nur umgekehrt. Die Anwendung ermittelt den Salt und den gespeicherten Hash des Benutzers, verarbeitet das eingegebene Passwort mit demselben Algorithmus und demselben Salt und vergleicht das Ergebnis mit dem gespeicherten Hash mittels eines Vergleichs in konstanter Zeit. Konstante Zeit ist entscheidend: Ein einfacher `==`-Vergleich gibt Informationen darüber preis, wie viele Bytes übereinstimmen, was zu echten Timing-Angriffen geführt hat. Verwenden Sie stattdessen `hmac.compare_digest`, `crypto.timingSafeEqual` oder die entsprechende Funktion Ihres Frameworks.

Warum Salzen wichtig ist: das Problem der Regenbogentabelle

Rainbow-Tabellen sind genau der Angriff, gegen den Salting entwickelt wurde. Stellen Sie sich eine vorab berechnete Tabelle vor, die jedes plausible Passwort – jedes Wörterbuchwort, jede gängige Variante, jeden Eintrag aus einer durchgesickerten Liste – seinem SHA-256-Hash zuordnet. Solche Tabellen existieren, werden in Cracking-Foren gehandelt und umfassen Terabytes. Sobald ein Angreifer einen Datenbank-Dump mit ungesalzenen Hashes besitzt, ist das Nachschlagen eines Hashs in einer Rainbow-Tabelle eine Datenbankabfrage und kein Cracking-Vorgang mehr. Genau so verlief der LinkedIn-Hack 2012: 117 Millionen ungesalzene SHA-1-Hashes wurden gegen eine Rainbow-Tabelle getestet, 90 Prozent davon wurden in etwa drei Tagen geknackt.

Fügt man benutzerbezogene Salt-Werte hinzu, funktionieren Rainbow-Tabellen nicht mehr. Der Angreifer bräuchte für jeden eindeutigen Salt-Wert eine separate, vorab berechnete Tabelle. Bei einem zufälligen Salt-Wert von 16 Byte wären das 117 Millionen verschiedene Tabellen für 117 Millionen Benutzer – und jede Tabelle wäre immer noch mehrere Terabyte groß. Allein die Speicherkosten machen dies unpraktikabel. Der Angriff fällt somit aus dem Bedrohungsmodell.

Das ist die Hauptaufgabe eines Salts. Er ist bewusst eingeschränkt. Ein Salt bremst einen gezielten Brute-Force-Angriff auf einen bestimmten Benutzer nicht aus. Er verhindert auch nicht das Ausnutzen von Anmeldeinformationen nach einem früheren Datenleck. Ein Salt hilft nicht, wenn das Passwort selbst „123456“ lautet – der Angreifer probiert das offensichtliche Wörterbuch aus, und der Salt wird für jeden Versuch neu berechnet, was die Kosten pro Versuch aber nicht wesentlich verändert.

Was Salting zuverlässig verhindert: Rainbow-Tabellen und das Auslesen von Informationen zur Passwortwiederverwendung zwischen Benutzern in derselben Datenbank. Was langsames Hashing verhindert: die Kosten pro Passwortversuch. Was Pepper verhindert: reinen Datenbankdiebstahl. Was MFA verhindert: Credential Stuffing. Salting ist eine Sicherheitsebene in einem umfassenden Sicherheitskonzept – das Hinzufügen eines Salts, um Passwörter schwerer zu knacken, ist nicht dasselbe, wie jedes Passwort einzeln schwer zu erraten. Ein individueller Hashwert für jeden Benutzer ist das Ziel von Salting; die Kosten pro Passwortversuch zu erhöhen, ist ein separates Problem.

Hashing vs. Verschlüsselung vs. Salting

Drei Begriffe, die oft verwechselt werden, insbesondere in Texten von Nicht-Fachleuten. Sie sind nicht austauschbar.

Verschlüsselung schützt Daten, die Sie später wiederherstellen möchten. Der Empfänger besitzt den Schlüssel, wendet ihn an und liest das Original. Hashing ist eine Einwegfunktion: Sobald ein Passwort zu einem Hashwert geworden ist, kann kein Algorithmus diesen umkehren. Salting ist ein Parameter, der auf die Eingabe einer Hash-Funktion angewendet wird – er hat allein keine Bedeutung.

Der Datendiebstahl bei Adobe im Jahr 2013 dient hier als warnendes Beispiel. Adobe speicherte 153 Millionen Benutzerdatensätze, indem Passwörter mit 3DES im ECB-Modus unter einem einzigen, seitenweiten Schlüssel verschlüsselt wurden. Diese Vorgehensweise erwies sich als dreifacher Fehler. Verschlüsselung ist für die Speicherung von Passwörtern ungeeignet. Der ECB-Modus führt dazu, dass identische Eingaben auch identische Ausgaben ergeben. Die Wiederverwendung eines Schlüssels für die gesamte Datenbank bedeutete, dass die einmalige Entschlüsselung des Schlüssels alle 153 Millionen Datensätze entschlüsselte. Schneier bezeichnete dies als einen der schwerwiegendsten Passwortdiebstähle der Geschichte. Die Lösung auf allen Ebenen bestand darin, auf gesalzenes, langsames Hashing umzusteigen.

Salz gegen Pfeffer: die zweischichtige Verteidigung

Pepper ist der weniger bekannte Verwandte von Salt. Das Konzept: ein zusätzlicher geheimer Wert, der auf jedes von der Anwendung verarbeitete Passwort angewendet, aber außerhalb der Datenbank gespeichert wird. Dies kann eine Umgebungsvariable, ein Eintrag in einem Schlüsselverwaltungssystem oder ein im HSM gespeicherter Schlüssel sein. Das Salt wird im Klartext zusammen mit dem Hash gespeichert. Das Pepper hingegen nicht.

Das Bedrohungsmodell basiert auf dem Diebstahl der Datenbank. Wenn ein Angreifer lediglich die Datenbank stiehlt – beispielsweise durch SQL-Injection, ein fehlerhaft konfiguriertes Backup oder einen durchgesickerten Datenbankabbild –, verfügt er zwar über Salts und Hashes, aber nicht über den Pepper. Ohne den Pepper kann er nicht einmal mit Brute-Force-Angriffen beginnen, da jeder Hash-Versuch den globalen geheimen Modifikator nicht enthält.

Eine typische Implementierung führt `argon2id(salt + password + pepper)` aus oder berechnet – genauer gesagt – zuerst `HMAC(pepper, password + salt)` und übergibt das Ergebnis an Argon2id. OWASP empfiehlt Pepper für sensible Systeme, weist aber auf den damit verbundenen Nachteil hin: Die Pepper-Rotation ist betrieblich aufwendig. Sie bedeutet, dass bei jeder Anmeldung das Passwort jedes Benutzers neu gehasht werden muss. Geht der Pepper ohne Backup verloren, sind alle Konten nicht mehr überprüfbar. Die meisten Verbraucheranwendungen verzichten auf Pepper. Anwendungen im Banken-, Regierungs- und Gesundheitswesen hingegen in der Regel.

Modernes Passwort-Hashing im Jahr 2026

Die OWASP-Richtlinien zur Passwortspeicherung von 2025 listen vier Algorithmen nach ihrer Präferenz auf. Salt ist in allen Algorithmen integriert – es muss nicht manuell generiert werden.

Argon2id ist speicherintensiv, d. h. jeder Hash-Versuch benötigt nicht nur CPU-Zyklen, sondern auch einen definierten RAM-Bereich. Der OWASP-Mindestbedarf von 19 MiB pro Hash bedeutet, dass ein Angreifer, der einen eigenen ASIC entwickelt, auch viel schnellen Speicher benötigt, und Speicher ist der teuerste Bestandteil jeder Hardware-Konfiguration. Die Variante „id“ kombiniert Argon2i (seitenkanalresistent) und Argon2d (GPU-resistent), indem sie in der ersten Hälfte Argon2i und in der zweiten Hälfte Argon2d ausführt.

scrypt ist älter als Argon2id und basiert auf demselben speicherintensiven Prinzip. bcrypt ist noch älter, einfacher und hat eine feste Eingabebeschränkung von 72 Byte, die gelegentlich bei Anwendungen mit langen Passphrasen Probleme verursacht. Für längere Eingaben empfiehlt sich ein Pre-Hash mit SHA-256 und anschließende Base64-Kodierung. PBKDF2 ist die langsame, aber FIPS-konforme Alternative; OWASP erhöhte die Iterationszahl für SHA-256 im Jahr 2023 von 310.000 auf 600.000.

Folgende Algorithmen gehören nicht auf diese Liste: einfaches SHA-256, einfaches SHA-512, MD5, SHA-1 und alle benutzerdefinierten Funktionen, die mit „+ Salt“ enden. Geschwindigkeit ist der entscheidende Faktor. SHA-256 wurde für hohe Geschwindigkeiten auf Standardhardware entwickelt. Das ist genau das Gegenteil dessen, was für die Passwortspeicherung erforderlich ist.

Häufige Fehler bei der Datenverarbeitung, die in realen Audits auftreten

In realen Sicherheitsvorfallberichten werden immer wieder dieselben wenigen Fehler hervorgehoben.

Die Wiederverwendung eines Salts für jeden Benutzer untergräbt den gesamten Mechanismus – das Rainbow-Table-Problem tritt erneut auf, nur mit einem zusätzlichen Schritt. Die Verwendung des Benutzernamens als Salt ist noch ineffizienter, da Benutzernamen systemübergreifend wiederholt auftreten und Rainbow-Tables für häufig verwendete Benutzernamen vorab berechnet werden können. Bei Salt-Längen unter 16 Byte treten bei großen Benutzerbasen Kollisionen auf. Die Generierung von Salt mit einer nicht-kryptografischen Zufallsfunktion – beispielsweise `Math.random()`, `time(0)` mod etwas oder dem Standard-Zufallszahlengenerator der Sprache – liefert vorhersehbare Werte, die den Nutzen des Salting zunichtemachen.

Ein subtilerer Fehler ist die Speicherung des Salts auf einem separaten Server „aus Sicherheitsgründen“. Der Salt ist kein Geheimnis. Die Aufteilung auf mehrere Systeme erhöht die Komplexität des Betriebs, ohne die kryptografische Sicherheit zu verbessern. Speichern Sie ihn in derselben Zeile wie den Hash. Moderne PHC-Strings erledigen dies automatisch.

Der größte Fehler, der bei den Audits 2026 auftritt, ist das Hashing mit einfachem SHA-256 plus Salt und die anschließende Übermittlung. Der Salt verhindert Rainbow-Tabellen. Er schützt jedoch nicht vor einer GPU-Farm, die zehn Milliarden Versuche pro Sekunde gegen ein einzelnes Konto durchführt. Die Lösung besteht nicht im Hinzufügen eines zweiten Salts, sondern im Wechsel zu einem langsamen KDF wie Argon2id.

Zuletzt: Ältere, ungesalzene Hashwerte. Die Migration ist zwingend erforderlich. Üblicherweise wird der ältere Hashwert beim nächsten Login überprüft, mit dem modernen Algorithmus neu berechnet und überschrieben. Für Benutzer, die sich danach nicht mehr anmelden, wird in regelmäßigen Abständen ein neues Passwort angefordert.

Warum Salzen allein nicht ausreicht

Salting ist eine zusätzliche Schutzschicht, keine Festung. Es wehrt einen bestimmten Angriff ab – vorab berechnete Tabellen – und gibt nichts über die Stärke des zugrundeliegenden Passworts preis. Brute-Force-Angriffe funktionieren weiterhin gegen schwache Passwörter. Credential Stuffing funktioniert weiterhin gegen wiederverwendete Passwörter. Phishing funktioniert weiterhin gegen jedes beliebige Passwort.

Echte Passwortsicherheit im Jahr 2026 basiert auf vier Schutzmechanismen. Argon2id mit einem 16 Byte großen Salt pro Benutzer verwaltet die Speicherung. Ein Pepper, optional, aber für sensible Systeme empfehlenswert, verhindert den Diebstahl von Daten aus der Datenbank. Multi-Faktor-Authentifizierung schützt vor Credential Stuffing und den meisten Phishing-Angriffen. Kontinuierliche Überwachung von Sicherheitslücken – beispielsweise durch Dienste wie Have I Been Pwned und dessen API – erkennt sofort, wenn die Zugangsdaten eines Benutzers in einem Datenleck auftauchen, sodass dieser zum Zurücksetzen gezwungen werden kann.

Lässt man eine dieser Sicherheitsebenen außer Acht, findet ein Angreifer früher oder später die Schwachstelle. Allein das sogenannte Salting oder eine einzelne Schutzmaßnahme hat sich in jeder Analyse von Sicherheitsvorfällen im letzten Jahrzehnt als entscheidender Fehler herausgestellt.

Jordan Morris

Jordan Morris is an AI expert with over a decade of experience and the author of a widely-read blog focused on artificial intelligence. His content spans a range of topics—from the ethics of machine learning to real-world applications of neural networks in business. Known for his clear writing and deep insights, Jordan has become a trusted voice in the AI community, appealing to both newcomers and seasoned professionals alike.