Begriff
Salt (Cryptography)
Warum wichtig?
Dieser Begriff ist ein Knoten im SengakujiWorks-Wissensnetz. Nutze Level 0 für die erste Einordnung, Level 1 für Praxis, Level 2 für technische Struktur und Level 3 für Grenzen, Fallstricke und Expertenkontext.
Wenn zwei User das gleiche Passwort haben ("geheim123"), haben sie auch den gleichen Hash. Ein Hacker sieht in der Datenbank: "Aha, User A und User B haben das gleiche Passwort." Und er kann eine Rainbow Table nutzen. Um das zu verhindern, gibt man Salz dazu. Rezept:
- Generiere eine Zufallszahl (Salt) für User A: "X9z".
- Hash =
sha256("geheim123" + "X9z"). - Speichere Salt ("X9z") offen neben dem Hash in der Datenbank.
Auch wenn User B auch "geheim123" nutzt, kriegt er ein anderes Salt ("A7b") -> Der Hash sieht komplett anders aus.
Merksatz: Zufällige Daten, die vor dem Hashen an ein Passwort angehängt werden, um identische Passwörter unterschiedlich aussehen zu lassen und Rainbow-Table-Angriffe zu verhindern.
Du musst es (hoffentlich) nie selbst bauen.
Bibliotheken wie bcrypt machen das automatisch.
hashed = bcrypt.hashpw(password, bcrypt.gensalt())
Niemals das Salt selbst erfinden ("MeinSaltIstSuper"). Nutze immer kryptografisch starke Zufallsgeneratoren (/dev/urandom).
1. Salt Length (Länge)
Das Salt muss lang genug sein, damit es weltweit einzigartig ist. Empfehlung: Mindestens 128 Bit (16 Bytes). Wenn das Salt zu kurz ist (z. B. nur 3 Zeichen), kann ein Hacker eine Rainbow Table für alle möglichen Salts bauen.
2. Salt Reuse (Wiederverwendung)
Don't. Jeder User braucht ein eigenes Salt. Wenn du ein "Global Salt" für die ganze App nimmst, hast du wieder das Problem, dass gleiche Passwörter gleich aussehen (nur global verschoben). Das verhindert Rainbow Tables nur bedingt.
3. Salt vs. Pepper
- Salt: Wird in der DB gespeichert. Hilft gegen Rainbow Tables. Ist NICHT geheim.
- Pepper: Ein geheimer Schlüssel, der nicht in der DB liegt (sondern im Code/HSM). Hilft, wenn die DB geklaut wird (aber der Code-Server sicher bleibt).
1. Key Derivation Functions (KDF: Argon2 vs. PBKDF2)
Salting allein hilft nur begrenzt. Wenn der Hacker die DB stiehlt, Rainbow-Tables blockiert sind, kauft er halt eine dedizierte RTX 4090 GPU Farm und hasht das Passwort "Peter1" iterativ mit allen gefundenen Salts ("Brute Force"). Ein roher Hash wie SHA-256 (welcher extrem auf Speed getrimmt ist), lässt Bitcoins Milliarden Hashes in Millisekunden berechnen. Deshalb weicht man zwingend auf Key Derivation Functions (KDF) aus, wie Argon2 oder bcrypt. Diese sind algorithmisch absichtlich langsam designt. Ein Argon2 Ansatz dauert z.B. 500 ms (CPU Limit), blockt aber vor allem GPUs aus (Memory-Hard). Argon2 krallt sich hart 1GB RAM vom System, der für Matrixmultiplikationen reserviert wird. Da GPUs rasante Taktungen, aber fast null Cache-Speicher pro Core haben, drosseln GPUs Argon2 extrem stark, was ASIC/GPU Attacken völlig ausbremst.
2. Hash-Rotation und Salting Upgrade Strategies
Ein System aus 2010 nutzt MD5 ohne Salt. Wie migriert man 1 Million User sicher auf Argon2, ohne sie aufzufordern, das Passwort zurückzusetzen? Lazy Migration (Upgrade on Login). Wenn der User sich das nächste Mal anmeldet (und sein Klartext Passwort "Hund" sendet), rechnet das Backend die MD5-Gegenprobe. Stimmt das Passwort? Wenn ja: Das Backend nimmt den Klartext, jagt ihn sofort in ein neues, sicheres Argon2(128bit Salt), wirft den obsoleten MD5-Hash aus der DB fort, speichert das Argon2 Format und lässt den Login zu. Dieses Upgrade geschieht völlig schleichend durch Usability-Prozesse.
3. Die HMAC Pepper Architektur (HSM-Secrets)
Salts liegen unsicher neben dem Hash in der gehackten Tabelle. Ein SQL-Injection-Dump offenbart beides: <hash>, <salt>.
Profi-Systeme fügen den Pepper (einen extrem langen High-Entropy Key) hinzu.
Der Flow ist oft: HMAC-SHA256( Argon2(Password + UserSalt), PEPPER_KEY ).
Der Pfeffer liegt NIEMALS in der SQL Datenbank.
Er ist entweder hart in Umgebungsvariablen (.env) oder idealerweise in einem Hardware Security Module (AWS KMS / HashiCorp Vault) fest verbaut.
Folge: Selbst wenn die gesamte SQL Tabelle mit Salt+Hashes geraubt wurde und als 10 GB Dump im Darknet steht, kann der Hacker lokal auf seinem Gaming-PC nicht ein einziges Passwort per Brute-Force verifizieren, solange nicht simultan das unzugängliche HSM/Backend Server-Modul mit dem Master-Pepper kompromittiert wurde. Separation of Concerns.
Quick-Check
Muss das Salt geheim sein?
Nein! Es steht meist im Klartext in der gleichen Datenbank-Zeile wie der Hash. Sein einziger Zweck ist Einzigartigkeit, nicht Geheimhaltung.Client-Side Salting?
Das Passwort schon im Browser salzen und hashen? Schlechte Idee. Dann ist der Hash das "neue Passwort". Wenn der Hacker den Hash klaut, kann er sich damit einloggen (Pass-the-Hash). Hashing gehört auf den Server.Kollision im Salt?
Extrem unwahrscheinlich bei 128 Bit. Und selbst wenn: Dann haben halt zufällig zwei User das gleiche Salt. Kein Sicherheitsbruch, nur ein minimaler Zufall.