Passwortsicherheit verstehen

Datenlecks der vergangenen Jahre haben Milliarden Passwörter offengelegt. Wo schlechte Hash-Verfahren im Einsatz waren, konnten Angreifer einen Großteil davon innerhalb von Stunden oder Tagen brechen. Diese Listen kursieren bis heute und werden für Credential Stuffing gegen fremde Dienste verwendet.

Wer Auth-Systeme baut, prüft oder defensiv betreibt, beeinflusst direkt, wie gut die eigenen Nutzer im nächsten großen Leak geschützt sind.

Statt das Passwort selbst zu speichern, speichert das System nur einen Hash. Bei der Anmeldung wird das eingegebene Passwort erneut gehasht und mit dem gespeicherten Wert verglichen. Wichtig sind drei Eigenschaften:

• Langsam: Verfahren wie Argon2id, bcrypt oder scrypt sind absichtlich rechenintensiv, damit Brute-Force teuer wird.
• Gesalzen: Ein zufälliger Salt pro Nutzer macht Rainbow Tables wertlos und schützt gleiche Passwörter unterschiedlicher Nutzer.
• Aufrüstbar: Der Kostenparameter lässt sich anheben, wenn Hardware schneller wird.

Ein einfacher SHA-256-Hash erfüllt nichts davon und ist für Passwörter ungeeignet, egal wie modern der Algorithmus klingt.

Es gibt einige wenige, immer wiederkehrende Angriffsformen, die du verstehen musst, um sinnvolle Verteidigungen zu bauen:

• Brute-Force: systematisches Durchprobieren. Wirksam nur gegen schwache Verfahren oder kurze Passwörter.
• Wörterbuchangriffe: Listen typischer Passwörter, kombiniert mit Regeln (z. B. Ziffern anhängen, Buchstaben tauschen).
• Rainbow Tables: vorberechnete Hash-Tabellen. Salts machen sie nutzlos.
• Credential Stuffing: nutzt Leaks aus fremden Diensten - hier helfen nur eindeutige Passwörter und MFA.
• Phishing: umgeht jeden Hash, weil das Passwort freiwillig eingegeben wird.

Ein zweiter Faktor schützt selbst dann, wenn das Passwort kompromittiert ist. Nicht jeder Faktor ist gleich stark:

• SMS-Codes: besser als nichts, anfällig für SIM-Swapping.
• TOTP-Apps (z. B. Authenticator-Apps): guter Standard, aber phishbar.
• WebAuthn / Passkeys: phishing-resistent, an Domain gebunden, langfristiger Standard.

Wer heute neu baut, sollte Passkeys von Anfang an mitdenken - auch wenn Passwörter noch als Fallback bleiben.

• Eigenes "verbessertes" Hash-Verfahren erfinden statt erprobte Libraries zu nutzen.
• Salt zu kurz oder global statt pro Nutzer.
• Kostenparameter so niedrig setzen, dass moderne GPUs Sekundenbruchteile brauchen.
• Passwörter im Klartext loggen oder per E-Mail zurückschicken.
• MFA als optional für Admin-Accounts.

• "SHA-256 ist sicher" - als Hash ja, für Passwortspeicherung nein.
• "Salt muss geheim sein" - nein, der Salt darf öffentlich neben dem Hash stehen. Geheim muss der Pepper sein, falls vorhanden.
• "Komplexitaetsregeln machen Passwörter sicher" - in der Praxis führen sie zu vorhersehbaren Mustern. Länge schlaegt Sonderzeichen.
• "Wer regelmäßig wechselt, ist sicher" - Zwangsrotation gilt heute als kontraproduktiv, wenn keine konkrete Kompromittierung vorliegt.

Legale Übung: Erzeuge in einem eigenen Python-Skript je einen Hash desselben Passworts mit MD5, SHA-256, bcrypt und Argon2id. Vergleiche Länge, Format und Berechnungszeit.

Portfolio-Idee: Baue eine kleine Demo-App, die Passwörter sauber speichert (Argon2id + per-User-Salt), Rate-Limiting und TOTP-MFA bietet. Dokumentiere die Entscheidungen im Repo.

Für Crack-Übungen erzeuge eigene Test-Hashes auf deinem System und arbeite mit hashcat in deinem Lab.