Ein Passwort mit SHA-256 zu hashen wirkt vernünftig: Der Klartext wird nicht gespeichert, und die Funktion ist nicht direkt umkehrbar. Das Problem ist Geschwindigkeit. Nach einem Datenbankdiebstahl muss ein Angreifer keinen Digest „entschlüsseln“. Er probiert wahrscheinliche Passwörter, hasht sie und vergleicht die Ergebnisse. Ein allgemeiner schneller Hash erlaubt enorme Versuchszahlen. Passwort-Hashing ist deshalb absichtlich teuer.

Der wichtigste Angriff findet offline statt

Beim normalen Login begrenzen Rate Limits, MFA und Missbrauchserkennung die Versuche. Eine gestohlene Hashdatenbank entfernt diese Schranken. Der Angreifer nutzt eigene GPUs oder Spezialhardware, ohne weitere Requests an die Anwendung zu senden.

Menschliche Passwörter besitzen häufig geringe Entropie und folgen bekannten Mustern. Die Verteidigung muss jeden Guess so teuer machen, dass die gesamte Suche langsamer und kostspieliger wird.

Ein Salt trennt gleiche Passwörter

Ein zufälliger, eindeutiger Salt wird gemeinsam mit dem Passwort verarbeitet. Zwei Konten mit demselben Passwort erhalten verschiedene gespeicherte Hashes. Vorberechnete Tabellen können dadurch nicht für die gesamte Datenbank wiederverwendet werden.

Der Salt muss nicht geheim sein. Moderne Bibliotheken erzeugen ihn und speichern ihn zusammen mit Algorithmus und Parametern in einem standardisierten String. Eigene Formate erhöhen Fehler- und Migrationsrisiko.

Spezielle Algorithmen sind absichtlich langsam

Argon2, scrypt, bcrypt und PBKDF2 besitzen konfigurierbare Kosten. Argon2 und scrypt können zusätzlich viel Speicher verlangen und reduzieren damit den Vorteil hochparalleler Hardware. Das Ziel ist nicht, Login unbenutzbar zu machen, sondern den höchsten vertretbaren Preis pro Versuch zu setzen.

Manuelles tausendfaches SHA-256 ersetzt kein geprüftes Password-KDF. Konstruktion, Saltverarbeitung, Parameterformat und Angriffsresistenz wurden bei spezialisierten Verfahren gezielt untersucht.

Parameter müssen mit Hardware wachsen

Was heute teuer ist, wird auf künftigen Prozessoren billiger. Der gespeicherte Hash sollte Algorithmus und Kosten enthalten. Nach einem erfolgreichen Login kann die Anwendung erkennen, dass ein Datensatz veraltet ist, und ihn mit aktuellen Einstellungen neu hashen.

Diese schrittweise Migration benötigt den Klartext nur im Moment der ohnehin stattfindenden Anmeldung. Konten, die lange inaktiv bleiben, können bei hohem Risiko gezielt zum Reset aufgefordert werden.

Benchmarking muss reale Last berücksichtigen

Ein einzelner Hash auf einem Entwicklerlaptop ist keine ausreichende Messung. Produktion verarbeitet parallele Logins, Autoscaling, unbekannte Benutzer und möglicherweise mehrere Anwendungsknoten. Parameter sollten auf realer Hardware unter erwarteter Konkurrenz getestet werden.

Zu niedrige Kosten helfen dem Angreifer; zu hohe Kosten ermöglichen Online-DoS. Rate Limits, Kapazitätsplanung und ein repräsentativer Hash für nicht existierende Konten gehören zusammen.

Ein Pepper ist ein separates Geheimnis

Manche Systeme ergänzen einen serverseitigen Pepper, der nicht in der Passwortdatenbank liegt. Leakt nur die Datenbank, fehlt dem Angreifer ein weiterer Wert. Der Pepper gehört in einen Secret Manager und braucht Backup- sowie Rotationsstrategie.

Er ersetzt weder Salt noch ein starkes Verfahren. Geht der Pepper verloren, können keine Passwörter mehr verifiziert werden. Sein betrieblicher Lebenszyklus ist daher genauso wichtig wie sein kryptografischer Nutzen.

Passwörter dürfen nicht wiederherstellbar sein

Wenn Support das aktuelle Passwort zusenden kann, wurde es im Klartext oder reversibel gespeichert. Ein sicheres System kann nur prüfen, ob eine Eingabe passt, und bietet ansonsten einen Reset an.

Reset-Tokens müssen zufällig, kurzlebig, einmalig und zweckgebunden sein. Sie werden ebenfalls geschützt gespeichert. Nach erfolgreichem Reset sollten offene Tokens und je nach Policy bestehende Sitzungen ungültig werden.

Normalisierung muss stabil und vorhersehbar sein

Unterschiedliches Trimming oder Unicode-Normalisieren bei Registrierung und Login kann Nutzer aussperren. Ein Passwort ist grundsätzlich eine exakte Zeichenfolge. Wenn die Anwendung Eingaberegeln besitzt, müssen sie vor dem ersten Hash dokumentiert und in allen Clients identisch sein.

Stille Änderungen an bestehenden Regeln sind riskant. Passwortmanager und Passkeys reduzieren die Notwendigkeit, exotische Zeichen künstlich einzuschränken.

Loginantworten dürfen Konten nicht verraten

Unterschiedliche Meldungen oder stark abweichende Laufzeiten ermöglichen Benutzeraufzählung. Anwendungen können für unbekannte Konten eine repräsentative Hashprüfung ausführen und eine neutrale Antwort senden.

Rate Limiting sollte Konto, Netzwerk und größere Missbrauchsmuster berücksichtigen. Eine pauschale dauerhafte Sperre nach wenigen Versuchen kann selbst als Angriff gegen echte Nutzer verwendet werden.

Breached-Password-Screening ergänzt Hashing

Bekannte kompromittierte Passwörter sollten bei Registrierung und Änderung abgelehnt werden. Dienste mit Prefix-Suche oder lokale Listen ermöglichen die Prüfung, ohne den vollständigen Kandidaten an Dritte zu senden.

Länge, Passwortmanager-Unterstützung und Sperrung bekannter Werte sind meist sinnvoller als komplizierte Symbolregeln. MFA und Passkeys begrenzen zusätzlich die Wirkung eines einzelnen gestohlenen Geheimnisses.

Ein Vorfall braucht einen vorbereiteten Ablauf

Starkes Hashing kauft Zeit, macht einen Leak aber nicht harmlos. Das Team muss wissen, welche Algorithmen und Parameter aktiv sind, wann Resets erforderlich werden und welche Sessions oder Refresh Tokens widerrufen werden.

Monitoring auf Credential Stuffing und klare Nutzerkommunikation gehören zur Reaktion. Ohne Inventar ist unklar, welche Konten den schwächsten Schutz besitzen.

Maschinenkonten brauchen andere Credentials

Technische Konten verdienen ebenfalls starkes Hashing, wenn sie sich mit Passwort anmelden. Oft sind rotierbare API-Schlüssel, Clientzertifikate oder Workload Identity geeigneter. Maschinengeheimnisse haben andere Erzeugungs- und Verteilungswege als menschliche Passwörter.

Ein guter Hash kompensiert keine Credentials in Images, Scripts oder gemeinsam genutzten Dokumenten. Schutz umfasst den gesamten Lebenszyklus.

Passwortspeicherung ist eine eigene Sicherheitsdisziplin

Schnelle Hashes identifizieren Daten; Password Hashes verteuern Guessing. Eine gepflegte Plattformbibliothek sollte Salt, Format und Verifikation übernehmen. Kostenparameter, Rehash und Vorfallplan bleiben Verantwortung der Anwendung.

Die richtige Lösung ist damit kein einzelner Algorithmusname, sondern ein aktualisierbarer Prozess aus starker Ableitung, sicherem Reset, Missbrauchsschutz und modernen Alternativen zum memorierten Passwort.