Wie sollten Passwörter gespeichert werden und warum bcrypt/scrypt/argon2 statt schneller Hashes verwenden?
Kurzantwort
Speichere Passwörter mit einer bewusst langsamen, gesalzenen, adaptiven Passwort-Hashfunktion – bcrypt, scrypt oder Argon2 – nie mit einem schnellen Allzweck-Hash wie SHA-256 oder MD5. Schnelle Hashes sind auf Geschwindigkeit ausgelegt, sodass Angreifer mit GPUs Milliarden Versuche pro Sekunde gegen eine geleakte Datenbank testen können. Langsame Hashes haben einen einstellbaren Arbeitsfaktor (und Speicherkosten), der jeden Versuch teuer macht und Brute Force selbst nach einem Leak unpraktikabel hält.
Dies ist eine alles entscheidende AppSec-Frage. Die falsche Antwort („wir SHA-256-en das Passwort") klingt verantwortungsvoll, ist aber genau der Fehler, der ein Datenbankleck in eine massenhafte Kontoübernahme verwandelt. Die Einsicht ist, dass Passwort-Hashing langsam sein will.
Warum schnelle Hashes scheitern
SHA-256, SHA-1 und MD5 sind auf Geschwindigkeit ausgelegt – eine Tugend für die Dateiintegrität, wo man Gigabyte schnell hasht. Doch Geschwindigkeit ist eine Belastung für Passwörter. Stiehlt ein Angreifer eine Tabelle gehashter Passwörter, knackt er sie offline, und mit modernen GPUs kann er Milliarden schneller Hash-Versuche pro Sekunde berechnen. In Verbindung mit geleakten Wortlisten und der Tatsache, dass Benutzer vorhersehbare Passwörter wählen, fallen die meisten schnell gehashten Passwörter binnen Stunden. Salzen hilft gegen Vorberechnung, ändert aber nichts an der reinen Rate-Geschwindigkeit.
Warum langsame, adaptive Hashes gewinnen
Speziell entwickelte Passwort-Hashes kosten pro Auswertung bewusst viel:
- bcrypt hat einen einstellbaren Arbeitsfaktor (Cost), den du mit besserer Hardware über die Zeit erhöhst; er ist seit Jahrzehnten erprobt.
- scrypt fügt Speicherhärte hinzu und zwingt jeden Versuch, viel RAM zu verbrauchen, was billiges paralleles GPU-/ASIC-Knacken bremst.
- Argon2 (Gewinner der Password Hashing Competition) stimmt Zeit, Speicher und Parallelität unabhängig ab und ist die moderne Standardempfehlung.
Der gemeinsame Gedanke: Einen einzelnen Versuch etwa 100 ms statt einer Nanosekunde dauern zu lassen. Das ist für eine legitime Anmeldung unsichtbar, vervielfacht aber die Kosten eines Angreifers um Größenordnungen, sodass selbst eine geleakte Datenbank dem Knacken widersteht. Salts (pro Benutzer einzigartig) bleiben obendrein zwingend, um Rainbow Tables und Leaks identischer Hashes zu stoppen.
Warum nicht stattdessen verschlüsseln?
Verschlüsselung ist umkehrbar, was bedeutet, dass der Schlüssel irgendwo existiert – und wird der Schlüssel kompromittiert, ist jedes Passwort sofort wiederhergestellt. Hashing ist von Natur aus einwegfähig; du verifizierst, indem du die Eingabe neu hasht, nie durch Entschlüsseln. Du solltest den Klartext nie zurückbrauchen.
Worauf Interviewer achten
Das Benennen von bcrypt/scrypt/Argon2, das Erklären der Logik langsam-by-Design / Arbeitsfaktor, das Salzen obendrauf, die Speicherhärte als Bonus und ein entschiedenes „hashen, nicht verschlüsseln" mit Begründung.
Wahrscheinliche Anschlussfragen
- Warum ist Schnelligkeit eine Schwäche für einen Passwort-Hash, aber eine Stärke für eine Datei-Prüfsumme?
- Wovor schützt Argon2s Speicherhärte, was bcrypt nicht tut?
- Warum sollte man gespeicherte Passwörter nie (umkehrbar) verschlüsseln?