Sie entscheiden, wie Benutzerpasswörter gespeichert werden sollen. Was ist der richtige Ansatz?
Kurzantwort
Passwortspeicherung braucht einen absichtlich langsamen, gesalzenen, speicherharten Hash — bcrypt, scrypt oder Argon2 — damit das Knacken gestohlener Hashes teuer ist und Rainbow Tables nicht greifen. Ein schneller Hash wie SHA-256 lässt sich im großen Maßstab trivial per Brute Force knacken; reversible Verschlüsselung bedeutet, dass eine einzige Schlüsselkompromittierung alle Passwörter auf einmal offenlegt; und Klartext ist unhaltbar, egal wie abgeriegelt die Datenbank ist. Wählen Sie Argon2id (oder bcrypt) mit einem abgestimmten Kostenfaktor und einem einzigartigen Salt pro Benutzer.
Passwörter zu speichern ist ein Problem mit feststehender Antwort, und Interviewer stellen es, um zu sehen, ob Sie zur zweckgebauten Primitive greifen oder zu einer, die nur kryptografisch klingt. Die richtige Wahl ist ein langsamer, gesalzener, speicherharter Passwort-Hash: Argon2 (id-Variante), bcrypt oder scrypt.
Warum langsam-und-gesalzen das richtige Werkzeug ist
Diese Funktionen sind für die Speicherung von Zugangsdaten ausgelegt. Sie sind absichtlich teuer zu berechnen (abstimmbarer Kostenfaktor / Speicherkosten), sodass ein Angreifer, der die Hash-Datenbank stiehlt, Rateversuche nur langsam testen kann — was ein GPU-Cracking von Milliarden pro Sekunde in ein Kriechen von Tausenden pro Sekunde verwandelt. Ein einzigartiger Salt pro Benutzer sorgt dafür, dass identische Passwörter unterschiedliche Hashes erzeugen, was vorberechnete Rainbow Tables schlägt und verhindert, dass ein Angreifer viele Konten auf einmal knackt. Die Speicherhärte von Argon2 dämpft GPU- und ASIC-Angriffe zusätzlich.
Warum jede Alternative scheitert
- SHA-256 ist ein schneller, allgemeiner Hash — genau die falsche Eigenschaft hier. Moderne Hardware berechnet Milliarden SHA-256-Hashes pro Sekunde, also fallen gestohlene Hashes schnell, und ungesalzene fallen sofort gegen Rainbow Tables.
- Passwörter mit AES zu verschlüsseln macht sie reversibel: Der Server muss den Schlüssel halten, also legt eine einzige Schlüsselkompromittierung (oder ein böswilliger Insider) alle Passwörter im Klartext offen. Außerdem müssen Sie das Originalpasswort nie wiederherstellen — nur verifizieren — daher ist Reversibilität reiner Nachteil.
- Klartext „aber die Datenbank abriegeln" ist unhaltbar. Ein einziges Backup-Leck, eine SQL-Injection oder ein fehlkonfiguriertes Replikat, und alle Zugangsdaten sind weg. Datenbank-ACLs ersetzen nicht das Nicht-Speichern des Geheimnisses.
Was eine starke Antwort ergänzt
Nennen Sie Argon2id (oder bcrypt) mit abgestimmten Kosten und Salt pro Benutzer; erwähnen Sie einen optionalen Pepper (einen außerhalb der Datenbank gehaltenen Geheimschlüssel) als Verteidigung in der Tiefe; und merken Sie an, dass Sie beim Login neu hashen würden, um Altdaten mit schnellem Hash zu migrieren, und den Kostenfaktor mit der Zeit erhöhen, während sich die Hardware verbessert.
Wahrscheinliche Anschlussfragen
- Welche Kostenfaktor- bzw. Speicher-/Zeit-Parameter würden Sie für Argon2id wählen, und warum sie abstimmen?
- Warum schlägt ein Salt pro Benutzer Rainbow Tables, und welchen zusätzlichen Wert bietet ein Pepper?
- Wie würden Sie Millionen bestehender SHA-256-Hashes nach Argon2 migrieren, ohne ein Zurücksetzen zu erzwingen?