Passwort-Hashing (bcrypt, Argon2, …)
Erstmal einfach — Warum ein eigener Hash für Passwörter?
Normale Hashes wie SHA-256 sind absichtlich schnell — Milliarden pro Sekunde auf einer GPU. Für Datei-Integrität super, für Passwörter eine Katastrophe: Angreifer können geleakte Passwort-Datenbanken massenhaft per Brute-Force durchtesten.
Passwort-Hashes sind das Gegenteil: absichtlich langsam und speicherhungrig, damit Massen-Raten unbezahlbar wird.
Probier's aus: Kostenfaktor
Wir simulieren das mit wiederholtem SHA-256 (echtes bcrypt/Argon2 ist anders gebaut, aber das Prinzip ist dasselbe). Schieb den Slider hoch — die Hash-Berechnung wird exponentiell langsamer.
Warum eigentlich? — Salt — wofür und warum zufällig?
Ohne Salt: zwei Nutzer mit demselben Passwort haben denselben Hash. Angreifer können vorberechnete Rainbow Tables bauen — riesige Listen „Hash → Passwort" — und alle Nutzer der DB auf einen Schlag knacken.
Mit zufälligem Salt pro Nutzer ist jeder Hash einzigartig, selbst bei identischem Passwort. Rainbow Tables werden nutzlos, der Angreifer muss für jeden Nutzer einzeln brute-forcen.
Salt darf öffentlich sein — es wird zusammen mit dem Hash in der DB gespeichert. Es muss nur einzigartig und zufällig sein.
Tiefer rein — bcrypt vs. scrypt vs. Argon2
- bcrypt (1999): Auf Blowfish basiert. Hat einen einstellbaren Kostenfaktor (Iterationen). Lange der Standard, aber limitiert auf 72 Zeichen Eingabe und nur CPU-hart — eine GPU bringt schon einen Vorteil.
- scrypt (2009): Zusätzlich speicherhart. Braucht viel RAM, was GPUs (mit wenig RAM pro Core) ausbremst.
- Argon2 (2015): Gewinner der Password Hashing Competition. Drei Parameter: Iterationen, Speicher, Parallelität.Argon2id ist heute die empfohlene Variante.
- PBKDF2 (1999): Älter, nur CPU-hart, aber sehr weit verbreitet (in WiFi/WPA2, im OS-Keystore). OK als Notlösung, nicht mehr erste Wahl.
Häufiger Denkfehler — Häufige Fehler in Login-Code
- SHA-256 statt bcrypt/Argon2. Klassischer Anfängerfehler. Schon mehrfach in echten Leaks gesehen.
- Globaler Salt statt einer pro Nutzer. Bringt fast nichts: ein vorberechneter Tisch reicht.
- Kein Pepper. Ein Pepper ist ein zusätzlicher geheimer Wert, der nicht in der DB liegt (z. B. im App-Server-Config). Falls die DB allein leakt, sind alle Hashes ohne Pepper nutzlos.
- Timing-Leaks beim Vergleichen:
===kann früh abbrechen und Bits über den richtigen Hash verraten. Lösung: konstanter Vergleich (crypto.timingSafeEqualin Node).