Wovor das Hashing eines Passworts Sie tatsächlich schützt

Die Kurzfassung

Das Hashing eines Passworts schützt Nutzer, wenn Ihre Passwortdatenbank gestohlen wird.

Das ist die Hauptaufgabe. Nicht das einzige Detail, nicht das gesamte Sicherheitsmodell, aber der zentrale Grund, warum wir Passwörter hashen, statt sie direkt zu speichern.

Ein korrekt gehashtes Passwort ist schwer umzukehren. Wenn ein Angreifer eine Kopie Ihrer Benutzertabelle erhält, sollte er nicht sofort erfahren, dass Alices Passwort Spring2026! lautet. Stattdessen erhält er einen gespeicherten Hash, dessen Prüfung gegen Vermutungen Zeit, Geld und Hardware kostet.

Diese Unterscheidung ist wichtig. Passwort-Hashing soll den Login nicht allein sicher machen. Es verhindert kein Phishing. Es verhindert nicht, dass jemand geleakte Passwörter gegen Ihr Login-Formular ausprobiert. Es schützt kein Session-Cookie nach dem Login. Es verschafft Zeit und reduziert Schaden nach einem sehr spezifischen Fehler: Der Speicher Ihrer Passwort-Verifier wird offengelegt.

Wenn Sie diese Grenze verstehen, treffen Sie bessere Entscheidungen zu Algorithmen, Work Factors, Resets, Logging und Incident Response.

Was ein Passwort-Hash ist

Ein Passwort-Hash ist die Ausgabe einer Einwegfunktion, die auf ein Passwort angewendet wird, üblicherweise mit einem eindeutigen Salt und einem absichtlich langsamen Passwort-Hashing-Algorithmus.

Wenn ein Nutzer ein Konto erstellt, sollte das System ungefähr Folgendes tun:

1. Das Passwort über HTTPS empfangen.
2. Einen zufälligen, eindeutigen Salt erzeugen.
3. Passwort und Salt durch eine Passwort-Hashing-Funktion wie Argon2id, bcrypt, scrypt oder PBKDF2 laufen lassen.
4. Algorithmusname, Parameter, Salt und den resultierenden Hash speichern.
5. Das ursprüngliche Passwort verwerfen.

Wenn sich der Nutzer später anmeldet, wiederholt das System denselben Hashing-Prozess mit dem übermittelten Passwort und den gespeicherten Parametern. Wenn der resultierende Hash mit dem gespeicherten Hash übereinstimmt, ist der Login erfolgreich.

Der wichtige Punkt: Die Anwendung muss das ursprüngliche Passwort nicht kennen. Sie muss nur verifizieren, dass das übermittelte Passwort das erwartete Ergebnis erzeugt.

Darum ist das Speichern von Passwörtern mit reversibler Verschlüsselung meist das falsche Modell. Wenn Ihre Anwendung jedes Passwort entschlüsseln kann, kann jeder, der den Entschlüsselungsschlüssel stiehlt, dasselbe tun. Passwörter sollten normalerweise rückwärts nicht verifizierbar sein, nicht nur verborgen.

Wovor Hashing Sie schützt

1. Sofortige Offenlegung von Passwörtern nach einem Datenbankbruch

Wenn ein Angreifer eine Datenbank mit Klartextpasswörtern stiehlt, entsteht der Schaden sofort. Jedes Passwort ist offengelegt. Nutzer sind nicht nur auf Ihrer Website gefährdet, sondern überall dort, wo sie dieses Passwort wiederverwendet haben.

Wenn die Datenbank gut gehashte Passwörter enthält, hat der Angreifer mehr Arbeit. Er muss Kandidatenpasswörter erraten, jede Vermutung mit dem richtigen Salt und den richtigen Parametern hashen und das Ergebnis vergleichen.

Bei schwachen Passwörtern kann das trotzdem schnell gehen. Bei starken, eindeutigen Passwörtern kann es unpraktikabel sein.

Hashing verwandelt eine katastrophale Offenlegung in ein Rennen: Können Nutzer ihre Passwörter zurücksetzen, und können Sie den Vorfall eindämmen, bevor Angreifer viele davon knacken?

Das ist nicht perfekt. Es ist immer noch ein Sicherheitsvorfall. Aber es ist ein deutlich besserer Fehlermodus.

2. Massenangriffe gegen Ihre gesamte Nutzerbasis

Salts sind ein zentraler Bestandteil der Passwortspeicherung, weil sie verhindern, dass Angreifer viele Nutzer effizient auf einmal mit vorberechneten Tabellen angreifen.

Ein Salt ist nicht geheim. Er wird zusammen mit dem Hash gespeichert. Seine Aufgabe ist Eindeutigkeit.

Wenn zwei Nutzer dasselbe Passwort wählen, sorgen eindeutige Salts dafür, dass ihre gespeicherten Hashes unterschiedlich sind. Das verhindert, dass Angreifer auf einen Blick sehen, dass viele Nutzer dasselbe Passwort verwenden. Es verhindert außerdem klassische Rainbow-Table-Angriffe, bei denen Angreifer riesige vorberechnete Listen von Passwort-zu-Hash-Zuordnungen nutzen.

Ohne Salts kann ein geknackter Hash jeden Nutzer mit demselben Passwort offenlegen. Mit Salts muss jede Passwortvermutung für jeden Nutzer separat getestet werden.

3. Schnelles Offline-Raten

Sobald Angreifer eine Passwortdatenbank haben, können sie offline raten. Das bedeutet, Ihre Login-Rate-Limits, CAPTCHA, IP-Blocking und Überwachung spielen keine Rolle mehr. Der Angreifer kann Vermutungen auf eigener Hardware testen.

Hier ist die Wahl des Algorithmus entscheidend.

Allzweck-Hashes wie SHA-256 und SHA-512 sind darauf ausgelegt, schnell zu sein. Das ist gut für Dateiintegrität und digitale Signaturen. Für Passwortspeicherung ist es schlecht.

Passwort-Hashing-Algorithmen sind darauf ausgelegt, langsam, anpassbar und manchmal speicherhart zu sein. Argon2id, bcrypt, scrypt und PBKDF2 erlauben es alle, Kostenparameter so anzupassen, dass jede Vermutung spürbar Zeit kostet.

Argon2id wird für neue Systeme weithin empfohlen, weil es so konfiguriert werden kann, dass es sowohl CPU-Zeit als auch Speicher benötigt, was groß angelegtes GPU-Cracking teurer macht. bcrypt ist weiterhin verbreitet und akzeptabel, wenn es gut konfiguriert ist, hat aber Einschränkungen wie den Umgang mit Passwortlängen. PBKDF2 wird noch in einigen compliance-getriebenen Umgebungen verwendet, insbesondere dort, wo FIPS-validierte Komponenten erforderlich sind.

Das Prinzip ist einfach: legitime Logins akzeptabel schnell machen, während Milliarden von Vermutungen teuer werden.

Wovor Hashing Sie nicht schützt

1. Phishing

Wenn ein Nutzer sein Passwort in eine gefälschte Login-Seite eingibt, hilft Hashing auf Ihrem Server nicht. Der Angreifer erhält das Passwort, bevor Ihr System es je sieht.

Die Abwehrmaßnahmen sind hier andere: Multi-Faktor-Authentifizierung, Passkeys, Nutzerschulung, Domain-Hygiene, phishing-resistente Authentifizierung und sorgfältige Abläufe zum Zurücksetzen von Passwörtern.

Passwort-Hashing ist eine Absicherung für gespeicherte Geheimnisse. Es ist keine Verteidigung dagegen, dass Nutzer dazu gebracht werden, diese Geheimnisse preiszugeben.

2. Credential Stuffing

Credential Stuffing passiert, wenn Angreifer Benutzername-Passwort-Paare nehmen, die von einem Dienst geleakt wurden, und sie bei einem anderen ausprobieren.

Ihre Passwort-Hashes können hervorragend sein, und Credential Stuffing kann trotzdem funktionieren, wenn Nutzer Passwörter wiederverwenden.

Das ist ein Online-Angriff gegen Ihr Login-Formular, kein Offline-Angriff gegen Ihre Datenbank. Sie benötigen Rate Limiting, Anomalieerkennung, Prüfungen auf kompromittierte Passwörter, MFA und sinnvolle Sperrregeln, die keine einfachen Denial-of-Service-Möglichkeiten schaffen.

Dasselbe praktische Denken gilt für jedes exponierte Formular. Wenn Sie Ihre Authentifizierungsfläche überprüfen, lohnt es sich zu lesen, warum Ihr Kontaktformular Ihr größtes Spam-Risiko ist; die Mechanik unterscheidet sich, aber die Lektion ist ähnlich: Öffentliche Eingaben brauchen Missbrauchskontrollen, nicht nur sauberen Backend-Code.

3. Passwörter, die in Logs oder Analytics erfasst werden

Hashing hilft nur, wenn das Klartextpasswort schnell verworfen und nirgendwohin kopiert wird.

Häufige Fehler sind:

• Vollständige Request-Bodies bei fehlgeschlagenen Login-Versuchen zu loggen.
• Passwörter an Error-Monitoring-Tools zu senden.
• Passwortfelder in Session-Replay-Produkten zu erfassen.
• Zugangsdaten in URLs während schlecht gestalteter Reset- oder Migrationsabläufe aufzunehmen.
• Temporäre Klartextpasswörter während Importen zu speichern.

Diese Fehler umgehen Passwort-Hashing vollständig. Wenn Klartext in Logs, Backups, Data Warehouses oder Drittanbieter-Tools landet, ist Ihre Hash-Funktion irrelevant.

Behandeln Sie Passwortfelder als toxische Daten. Redigieren Sie sie vor dem Logging. Schließen Sie sie aus Analytics aus. Halten Sie sie aus URLs heraus. Begrenzen Sie, wer auf Produktions-Traces zugreifen kann.

4. Schlechte Session-Sicherheit

Nach dem Login erhält der Browser des Nutzers normalerweise ein Session-Cookie oder Token. Wenn dieses Token gestohlen wird, braucht der Angreifer das Passwort möglicherweise gar nicht.

Passwort-Hashing schützt nicht vor Cross-Site-Scripting, unsicheren Cookies, Session Fixation, schwacher Token-Erzeugung oder übermäßig langen Session-Laufzeiten.

Session-Cookies verdienen eine eigene Prüfung: HttpOnly, Secure, angemessenes SameSite, kurzlebige Hochrisiko-Sessions und serverseitige Invalidierung bei Passwortänderungen. Auch die breitere Datenschutz- und Browserlandschaft verschiebt sich weiter, wie in was sich 2026 bei Cookies geändert hat beschrieben.

5. Schwaches Zurücksetzen von Passwörtern und Account-Wiederherstellung

Viele Kontoübernahmen beginnen nicht mit dem Passwort. Sie beginnen mit dem Reset-Ablauf.

Wenn Reset-Tokens vorhersagbar, langlebig, über Referrer-Header geleakt oder an kompromittierte E-Mail-Konten gesendet werden, wird Passwort-Hashing Sie nicht retten.

Verwenden Sie Reset-Tokens mit hoher Entropie, kurze Ablaufzeiten, einmalige Nutzung und klare Nutzerbenachrichtigungen. Da E-Mail oft der Wiederherstellungskanal ist, ist auch grundlegende Domain-Authentifizierung wichtig. Wenn Ihr Team DNS-Einträge als mysteriöse Zeremonie behandelt, beginnen Sie mit einer entwicklerfreundlichen Tour durch MX, SPF, DKIM und DMARC.

Die Wahl des Algorithmus: was Sie jetzt verwenden sollten

Für neue Anwendungen verwenden Sie Argon2id, wenn Ihre Plattform es gut unterstützt. Es ist der Gewinner der Password Hashing Competition und wurde für Passwortspeicherung entwickelt, einschließlich Widerstand gegen GPU-lastiges Cracking.

Eine sinnvolle moderne Rangfolge sieht so aus:

1. Argon2id für neue Systeme, wo verfügbar.
2. bcrypt wenn Argon2id nicht praktikabel ist und bcrypt-Unterstützung ausgereift ist.
3. scrypt wenn speicherharte Konfiguration gut unterstützt wird.
4. PBKDF2 wo es durch Plattform- oder Compliance-Vorgaben erforderlich ist.

Vermeiden Sie einfaches SHA-256, SHA-512, MD5 oder eine selbstgebaute Kombination wie sha256(password + salt). Schnelle Hashes sind keine Funktionen zur Passwortspeicherung. Clevere Eigenkonstruktionen sind tendenziell schlechter als langweilige Standardlösungen.

Vermeiden Sie außerdem, Ihre eigene Passwortrichtlinie um Algorithmus-Trivia herum zu erfinden. Nutzer profitieren nicht von einer Passwort-Composition-Checkliste mit 12 Regeln, wenn sie dadurch zu vorhersehbaren Mustern gedrängt werden. Längere eindeutige Passwörter, Passwortmanager, Screening auf kompromittierte Passwörter und MFA sind meist wichtiger.

Cost Factors sind nicht einmal einstellen und vergessen

Passwort-Hashing hat Parameter. Argon2id hat Speicher, Iterationen und Parallelität. bcrypt hat einen Cost Factor. PBKDF2 hat eine Iterationszahl.

Diese Werte sollten auf Basis Ihrer Produktionsumgebung gewählt werden. Zu niedrig, und Angreifer raten günstig. Zu hoch, und Ihr Login-System wird langsam oder anfällig für Denial-of-Service.

Ein praktisches Ziel liegt oft im Bereich von einigen Dutzend bis wenigen Hundert Millisekunden pro Passwortverifikation auf Ihren tatsächlichen Servern, abhängig von Traffic und Risiko. Hochsicherheitssysteme können mehr wählen. Systeme im Consumer-Maßstab brauchen möglicherweise sorgfältige Kapazitätsplanung.

Kopieren Sie keinen Cost Factor aus einem fünf Jahre alten Blogpost. Hardware ändert sich. Bibliotheken ändern sich. Ihr Traffic ändert sich.

Überprüfen Sie Parameter regelmäßig und planen Sie Rehashing ein. Ein gängiges Muster ist, Algorithmus und Parameter mit jedem Hash zu speichern. Bei erfolgreichem Login wird, wenn die gespeicherten Parameter veraltet sind, das übermittelte Passwort mit der neueren Konfiguration erneut gehasht und der Datensatz aktualisiert.

Peppers: nützlich, aber kein Ersatz

Ein Pepper ist ein geheimer Wert, der dem Passwort-Hashing-Prozess hinzugefügt und getrennt von der Datenbank gespeichert wird, oft in einem Secrets Manager oder Hardware Security Module.

Anders als ein Salt muss ein Pepper geheim bleiben.

Peppers können den Schaden reduzieren, wenn die Datenbank leakt, die Anwendungsgeheimnisse aber nicht. Sie sind am nützlichsten in ausgereiften Umgebungen mit gutem Schlüsselmanagement. Sie sind weniger nützlich, wenn derselbe Angreifer sowohl die Datenbank als auch die Anwendungskonfiguration stehlen kann.

Wenn Sie einen Pepper verwenden, planen Sie die Rotation sorgfältig. Je nach Design kann seine Rotation erfordern, dass Nutzer sich erneut anmelden oder Passwörter zurücksetzen. Ein Pepper ist eine zusätzliche Schicht, kein Grund, die zugrunde liegenden Hash-Einstellungen abzuschwächen.

Die operative Checkliste

Wenn Sie für ein reales System verantwortlich sind, ist die praktische Checkliste kurz:

• Speichern Sie Passwörter nur mit einem standardisierten Passwort-Hashing-Algorithmus.
• Verwenden Sie pro Passwort einen eindeutigen zufälligen Salt.
• Bevorzugen Sie Argon2id für neue Builds.
• Stimmen Sie Kostenparameter auf produktionsähnlicher Hardware ab.
• Speichern Sie Algorithmus und Parameter mit jedem Hash.
• Hashen Sie beim Login neu, wenn Parameter veraltet sind.
• Loggen Sie niemals Passwörter und senden Sie sie nicht an Analytics-Tools.
• Verwenden Sie TLS überall dort, wo Zugangsdaten übermittelt werden.
• Fügen Sie MFA oder Passkeys hinzu, wo das Risiko es rechtfertigt.
• Schützen Sie Reset-Abläufe so ernsthaft wie Login-Abläufe.
• Haben Sie einen Incident-Plan für erzwungene Resets und Nutzerbenachrichtigung.

Passwort-Hashing ist nicht glamourös. Es ist Infrastruktur. Aber es ist die Art von Infrastruktur, die bestimmt, ob ein Sicherheitsbruch zu einem schmerzhaften Vorfall oder zu einer Katastrophe für alle Nutzer wird.

<!-- tool-cta:start -->

💡 Probieren Sie es aus: Sehen Sie mit dem Hash Generator, wie dieselbe Eingabe auf verschiedene Algorithmen abgebildet wird, wodurch der Unterschied zwischen schnellen Hashes und passworttauglichen Hashes greifbar wird.

<!-- tool-cta:end -->

Das ehrliche mentale Modell

Die beste Art, über Passwort-Hashing nachzudenken, ist diese:

Hashing schützt das Passwort nicht, während der Nutzer es eintippt. Es schützt das Konto nicht, nachdem der Nutzer angemeldet ist. Es schützt Nutzer nicht, die Passwörter im Web wiederverwenden.

Es schützt den gespeicherten Verifier.

Das klingt eng, ist aber extrem wichtig. Datenbanken leaken. Backups leaken. Staging-Systeme werden kopiert. Anbieter erhalten Zugriff, den sie nicht haben sollten. Alte Exporte liegen länger in Object Storage, als sich irgendjemand erinnert.

Wenn das passiert, macht Ihr Design der Passwortspeicherung den Unterschied zwischen Angreifern, die Passwörter erhalten, und Angreifern, die ein teures Rateproblem erhalten.

Davor schützt Sie das Hashing eines Passworts tatsächlich.