Passwortspeicherung: Was 2026 Richtig Ist

Die Passwortspeicherung ist einer der wenigen Bereiche der Softwareentwicklung mit einer echten richtigen Antwort, die veröffentlicht, gepflegt und kostenlos verfügbar ist. Sie ist zugleich einer der Bereiche, die am beharrlichsten falsch gemacht werden, weil die falschen Antworten irgendwann einmal richtig waren und niemand sie seither überprüft hat.

Das Versagen ist selten exotisch. Es ist ein System, das 2016 nach Empfehlungen gebaut wurde, die 2012 aktuell waren, das immer noch läuft, immer noch Anmeldungen entgegennimmt, und in dessen Hash-Funktion niemand mehr hineingesehen hat, seit die Person das Unternehmen verlassen hat, die sie geschrieben hatte.

Wenn Sie nur eines mitnehmen: Nutzen Sie Argon2id, und wenn das nicht möglich ist, nutzen Sie bcrypt. Alles andere in diesem Artikel ist Detail. Ein Allzweck-Hash wie SHA-256 ist kein Passwort-Hash, ganz gleich wie oft Sie ihn anwenden, denn seine Geschwindigkeit ist ein Konstruktionsziel, und genau diese Geschwindigkeit wollen Sie einem Angreifer verweigern, der Ihre Datenbank in Händen hält.

Passwortspeicherung hat genau eine richtige Form

Speichern Sie einen Hash, den eine bewusst langsame, speicherharte Funktion erzeugt hat, mit einem eindeutigen zufälligen Salt pro Passwort und mit Parametern, die auf Ihre Hardware abgestimmt sind.

Die OWASP-Leitlinie zur Passwortspeicherung formuliert die aktuellen Empfehlungen präzise, und es lohnt sich, sie als Zahlen zu zitieren und nicht als Prinzipien.

Zwei Anmerkungen zu dieser Tabelle. Der Argon2id-Wert ist ein Minimum, und mehr Speicher bei weniger Durchläufen ist ein gleichwertiger Tausch, sodass eine Konfiguration mit 47 MiB und 1 Iteration vergleichbare Sicherheit bietet wie die Basisempfehlung. Und die Grenze von 72 Byte bei bcrypt ist eine echte Kürzung und keine Prüfregel: Alles jenseits von 72 Byte wird stillschweigend ignoriert, was zählt, sobald Sie lange Passphrasen zulassen oder die Eingabe vorher hashen.

Diese Parameter werden angehoben, sobald sich die Hardware verbessert. Lesen Sie bei der Umsetzung die Quelle und nicht diese Tabelle.

Ein Salt ist nicht optional und nicht ausreichend

Ein Salt ist ein eindeutiger Zufallswert, der neben jedem Hash gespeichert wird. Sein Zweck ist eng gefasst und wichtig: Er sorgt dafür, dass zwei Nutzer mit demselben Passwort unterschiedliche Hashes erzeugen. Das entwertet vorberechnete Rainbow Tables und verhindert, dass ein Angreifer ein einziges Passwort knackt und damit jedes Konto erhält, das dasselbe Passwort verwendet hat.

Was ein Salt nicht leistet, ist irgendjemanden auszubremsen. Wer Ihre Datenbank hat, hat auch die Salts, denn sie müssen lesbar sein, um eine Anmeldung zu prüfen. Salting allein gegen einen schnellen Hash bedeutet, dass ein Angreifer jedes Passwort einzeln angreift, und zwar mit enormer Geschwindigkeit, was genau die Lage ist, die Sie vermeiden wollten.

Die Langsamkeit muss aus dem Algorithmus kommen. Genau darum geht es bei einer speicherharten Funktion: Sie verbraucht absichtlich Ressourcen, damit ein Angreifer mit spezialisierter Hardware weit weniger Vorteil gewinnt, als er gegen einen schnellen Hash hätte.

Ein Pepper, ein geheimer Wert, der auf jedes Passwort angewendet und außerhalb der Datenbank aufbewahrt wird, fügt eine echte Schicht hinzu, weil ein reiner Datenbankabzug dann nicht mehr genügt. Er bringt auch Betriebsaufwand mit sich, denn eine Rotation verlangt ein erneutes Hashen bei der nächsten Anmeldung, und wer ihn verliert, sperrt jedes Konto aus. Für hochwertige Systeme lohnt sich das, für die meisten anderen kann man darauf verzichten.

Die Fehler, die jahrelang überleben

Ein schneller Hash mit Salt. SHA-256 mit einem Salt wirkt verantwortungsvoll und ist es nicht. Die Geschwindigkeit ist die Schwachstelle.

Verschlüsselung statt Hashing. Verschlüsselung ist von Natur aus umkehrbar, es existiert also ein Schlüssel, und wer ihn erlangt, erlangt jedes Passwort im Klartext. Passwörter sollten niemals wiederherstellbar sein, sondern nur überprüfbar.

Einmal gesetzte und nie erhöhte Work Factors. Ein 2015 gewählter bcrypt-Kostenwert ist gegen Hardware von 2026 deutlich schwächer. Erhöhen Sie ihn bei der nächsten erfolgreichen Anmeldung, wenn Sie den Klartext kurz vorliegen haben und neu hashen können.

Kürzungen oder Zeichenbeschränkungen. Eine Maximallänge unterhalb von etwa 64 Zeichen oder ein Verbot bestimmter Zeichen deutet meist darauf hin, dass das Passwort auf eine Weise gespeichert wird, der sein Inhalt nicht gleichgültig ist. Das sollte er sein, denn Sie hashen es ohnehin.

Ein Vergleich, der Zeit verrät. Die Prüfung muss einen zeitkonstanten Vergleich verwenden. Funktionen der Standardbibliothek tun das, selbst gebaute Gleichheitsprüfungen nicht.

Das Passwort protokollieren. Es landet in einem Fehlerprotokoll, einem Request-Trace oder einem Monitoring-System und liegt dann an drei Stellen mit schwächeren Zugriffskontrollen als die Datenbank.

Ein bestehendes System migrieren

Sie können nicht neu hashen, was Sie nicht haben, denn Sie halten ausschließlich Hashes. Der praktikable Weg ist die Aufwertung bei der Anmeldung.

Wenn sich ein Nutzer erfolgreich authentifiziert, liegt sein Klartextpasswort für einen Moment im Speicher. Prüfen Sie es gegen den alten Hash und berechnen Sie sofort danach einen neuen mit dem aktuellen Algorithmus, der den gespeicherten Wert ersetzt. Über einige Monate wandern die meisten aktiven Konten ohne für die Nutzer sichtbare Änderung mit.

Führen Sie den Algorithmus pro Datensatz mit, damit beide nebeneinander bestehen können, und legen Sie ein Datum fest, ab dem verbliebene alte Hashes ungültig werden und die betroffenen Nutzer zurücksetzen müssen. Ruhende Konten mit schwachen Hashes sind genau die, die ein Angreifer haben will.

Verpacken Sie den alten Hash nicht als Abkürzung in den neuen Algorithmus. Das funktioniert, und es belässt den schwachen Hash als wirksame Sicherheitsgrenze, während alles modern aussieht.

Was mehr zählt als der Algorithmus

Korrektes Hashing schützt Sie, wenn die Datenbank abfließt. Gegen den häufigeren Angriff hilft es nicht, nämlich dagegen, dass sich jemand mit einem echten Passwort anmeldet, das er anderswo erbeutet hat.

Ratenbegrenzung an der Anmeldung, verfügbare Mehrfaktor-Authentifizierung, ein Abgleich neuer Passwörter gegen bekannte Leaklisten und Alarme bei Mustern von Credential Stuffing adressieren genau das, und alles davon zählt im Alltag mehr als die Wahl zwischen Argon2id und bcrypt. Die Kontrollen für API-Sicherheit gehören zur selben Problemfamilie.

Beides lohnt sich, und über die Reihenfolge sollte man ehrlich sein: Bringen Sie das Hashing einmal in Ordnung, weil es billig und dauerhaft ist, und stecken Sie die laufende Mühe danach in den Anmeldeweg, wo die Angriffe tatsächlich ankommen. Mecanik prüft beides im Rahmen unserer Anwendungssicherheitsanalyse.

Häufig gestellte Fragen

Was ist 2026 der beste Algorithmus zum Hashen von Passwörtern? Argon2id, mit mindestens 19 MiB Speicher, 2 Iterationen und 1 Grad an Parallelität. Ist er nicht verfügbar, ist scrypt mit N=2^17, r=8, p=1 eine Alternative, bcrypt mit einem Work Factor von 10 oder mehr passt zu Altsystemen, und PBKDF2-HMAC-SHA256 mit 600.000 Iterationen deckt FIPS-140-Anforderungen ab.

Genügt es, Passwörter zu salzen? Nein. Ein Salt sorgt dafür, dass identische Passwörter unterschiedliche Hashes ergeben, entwertet Rainbow Tables und verhindert, dass ein geknacktes Passwort jedes Konto öffnet, das es geteilt hat. Er bremst einen Angreifer nicht, weil Salts lesbar sein müssen, um Anmeldungen zu prüfen. Die Langsamkeit muss aus einem bewusst speicherharten Algorithmus kommen.

Warum nicht SHA-256 für Passwörter verwenden? Weil seine Geschwindigkeit ein Konstruktionsziel ist, und Geschwindigkeit ist genau das, was Sie einem Angreifer verweigern wollen, der Ihre Datenbank hält. Ein Allzweck-Hash ist kein Passwort-Hash, unabhängig davon, wie oft er angewendet wird oder ob er gesalzen ist.

Hat bcrypt eine Längenbegrenzung für Passwörter? Ja, 72 Byte, und alles darüber hinaus wird stillschweigend gekürzt statt abgelehnt. Das zählt, wenn Sie lange Passphrasen zulassen oder die Eingabe vor der Übergabe an bcrypt vorhashen, denn die Kürzung geschieht ohne jede Fehlermeldung.

Wie aktualisiere ich Passwort-Hashes ohne die Passwörter der Nutzer? Bei der Anmeldung. Wenn sich ein Nutzer authentifiziert, halten Sie seinen Klartext für einen Moment, prüfen ihn also gegen den alten Hash und hashen sofort mit dem aktuellen Algorithmus neu. Führen Sie den Algorithmus pro Datensatz mit, damit beide koexistieren, und legen Sie ein Datum fest, ab dem verbliebene alte Hashes ungültig werden und die betroffenen Nutzer zurücksetzen müssen.