Passwortspeicherung richtig gemacht: Hashing, Salting und bcrypt vs. Argon2 vs. PBKDF2

Kurz gesagt: Sichere Passwortspeicherung bedeutet, jedes Passwort mit einem einzigartigen, zufälligen Salt mithilfe eines langsamen, speicherintensiven Algorithmus zu hashen und es niemals im Klartext oder reversibel verschlüsselt zu speichern. Verwenden Sie für neue Systeme Argon2id mit den aktuellen OWASP-Parametern; für ältere Systeme weiterhin bcrypt mit einem Kostenfaktor von mindestens 12; verwenden Sie PBKDF2 nur, wenn die FIPS-Validierung dies erfordert. Empfohlene Vorgehensweise: Überprüfen Sie noch heute Ihren aktuellen Hash-Algorithmus und dessen Parameter, da es sich hierbei um eine kryptografische Implementierungsentscheidung handelt, die leicht unbemerkt falsch getroffen werden kann.

Veröffentlicht: Juni 2026 | Aktualisiert: August 2026 | Geprüft vom Kryptografie-Beratungsteam von Encryption Consulting

Die meisten Menschen machen sich nach der Registrierung keine Gedanken darüber, wie ihre Passwörter gespeichert werden. Sie vertrauen einfach darauf, dass Unternehmen korrekt damit umgehen. Doch dieses Vertrauen ist nicht immer gerechtfertigt. Die sichere Speicherung von Passwörtern gehört zu den am häufigsten vernachlässigten Bereichen der Anwendungssicherheit, und Fehler können schwerwiegende Folgen haben.

Jährlich werden durch Sicherheitslücken Millionen von Nutzerdaten offengelegt. Oftmals wurden diese Daten so gespeichert, dass sie leicht zu knacken waren: fehlendes Salting, schwache Hashwerte , manchmal sogar Klartext. Das sind keine Einzelfälle, sondern wiederkehrende Sicherheitslücken, die echte Nutzer betreffen.

Dieser Beitrag erklärt, wie sichere Passwortspeicherung aussieht – von den Grundlagen des Hashings und Salting bis hin zu einem praktischen Vergleich von bcrypt, Argon2 und PBKDF2. Wenn Sie ein Authentifizierungssystem entwickeln oder überprüfen, ist dies der ideale Ausgangspunkt.

Warum die sichere Speicherung von Passwörtern wichtig ist

Wenn Angreifer eine Passwortdatenbank stehlen, erhalten sie nicht sofort alle Passwörter. Sie besitzen lediglich gespeicherte Repräsentationen. Sind diese korrekt erstellt, sind die Daten für sie weitgehend wertlos. Andernfalls können sie innerhalb weniger Stunden Tausende von echten Passwörtern wiederherstellen.

Das Risiko beschränkt sich nicht auf ein einzelnes Konto. Viele Menschen verwenden Passwörter für verschiedene Dienste. Ein geknacktes Passwort einer scheinbar harmlosen App kann E-Mail-Konten, Online-Banking-Zugangsdaten oder sogar Firmensysteme kompromittieren. Diese Kettenreaktion verdeutlicht, warum selbst kleine Anwendungen eine Verantwortung für die umfassende Sicherheit ihrer Nutzer tragen.

Hinzu kommt der Aspekt der Einhaltung gesetzlicher Bestimmungen. Rahmenwerke wie NIST SP 800-63B, die DSGVO und PCI-DSS legen Anforderungen an den Schutz von Authentifizierungsdaten fest. Eine unzureichende Passwortverwaltung stellt sowohl ein technisches als auch ein regulatorisches Versagen dar und kann zu Strafen und Reputationsschäden führen.

Auf welchen Sicherheitsannahmen beruht diese Analyse?

Alle Empfehlungen in diesem Beitrag basieren auf einem spezifischen Bedrohungsmodell: Ein Angreifer, der die Passwortdatenbank offline erlangt hat – sei es durch einen Datenverstoß, Insiderinformationen oder eine fehlerhafte Datensicherung –, kann unbegrenzt Passwörter erraten, ohne dass Ratenbegrenzungen, Kontosperrungen oder Überwachungsmaßnahmen ergriffen werden. Dies ist die richtige Annahme für die Entwicklung von Sicherheitskonzepten, da Online-Ratenbegrenzungen eine Kontrollmaßnahme sind, die versagen oder umgangen werden kann, während die Offline-Resistenz gegen Passwortknacken eine Eigenschaft der gespeicherten Daten selbst ist.

Die Analyse geht außerdem davon aus, dass der Angreifer Zugriff auf handelsübliche GPU-Hardware hat und nicht auf eine ASIC-Farm eines Nationalstaats; sie geht davon aus, dass Passwörter aus dem tatsächlichen Nutzerverhalten stammen, was bedeutet, dass ein signifikanter Anteil kurz, wörterbuchbasiert oder wiederverwendet und nicht gleichmäßig zufällig ist; und sie geht davon aus, dass das Salt öffentlich ist (und zusammen mit dem Hash gespeichert wird, wie es sein sollte), sodass die Kosten des Algorithmus und nicht die Geheimhaltung des Salts das sind, was dem Angriff widerstehen muss.

Hashing und Passwort-Salting verstehen

Eine kryptografische Hash-Funktion nimmt ein Passwort als Eingabe und erzeugt eine Ausgabe fester Länge, den sogenannten Hash oder Digest. Entscheidend ist, dass dieser Prozess nur in eine Richtung funktioniert. Man kann einen Hash nicht umkehren, um das ursprüngliche Passwort wiederherzustellen. Daher speichern Systeme anstelle der Passwörter selbst deren Hashes. Beim Anmelden wird das eingegebene Passwort gehasht und mit dem gespeicherten Hash verglichen.

Das klingt sicher genug. Doch universelle Hashfunktionen wie MD5 und SHA-256 wurden für hohe Geschwindigkeiten entwickelt, nicht für Passwörter. Moderne GPUs können Milliarden von SHA-256-Hashes pro Sekunde berechnen. Diese Geschwindigkeit ist ein Vorteil für Angreifer, die Brute-Force- oder Wörterbuchangriffe durchführen.

Passwort-Salting schützt vor einer speziellen Angriffsmethode: Rainbow-Tabellen. Eine Rainbow-Tabelle ist eine vorab berechnete Liste von Hashwerten für gängige Passwörter. Ein Angreifer kann einen gestohlenen Hashwert verwenden und ihn innerhalb von Sekunden nachschlagen, ohne selbst Berechnungen durchführen zu müssen.

Ein Salt ist eine eindeutige, zufällig generierte Zeichenkette, die vor dem Hashing an jedes Passwort angehängt wird. Selbst wenn zwei Benutzer dasselbe Passwort verwenden, führen ihre Salts zu völlig unterschiedlichen Hashwerten. Dadurch werden Rainbow-Tabellen nutzlos und Angreifer müssen jeden Hash einzeln knacken.

Salts sind nicht geheim. Sie werden zusammen mit dem Hash gespeichert. Ihr Wert liegt in ihrer Einzigartigkeit und Zufälligkeit, nicht in ihrer Geheimhaltung. Salting ist keine Verschlüsselung. Es ist ein Mittel, um Angriffe vor der Berechnung abzuwehren.

Ein praktisches Beispiel: Warum die Wahl des Algorithmus alles verändert

Zahlen verdeutlichen den Unterschied. Nehmen wir ein 8-stelliges Passwort, das nur aus Kleinbuchstaben besteht: Es gibt etwa 208 Milliarden mögliche Kombinationen. Eine moderne Consumer-GPU kann über 10 Milliarden ungesalzene SHA-256-Hashes pro Sekunde berechnen. Das bedeutet, dass der Schlüsselraum in deutlich weniger als einer Minute erschöpft ist, ob mit oder ohne Salt. Denn das Salting verhindert zwar die Verwendung vorab berechneter Rainbow-Tabellen, verlangsamt aber nicht den Brute-Force-Angriff auf schnelle Hashes.

Führt man denselben Angriff auf ein mit Argon2id gespeichertes Passwort mit den von OWASP empfohlenen Basisbedingungen (46 MiB Speicher, 1 Iteration, 1 Grad Parallelität) durch, ändert sich das Bild. Dieselbe GPU, die zuvor 10 Milliarden SHA-256-Hashes pro Sekunde berechnete, wird nun nicht mehr durch die reine Rechenleistung, sondern durch die Speicherbandbreite begrenzt und schafft bei diesem Speicheraufwand typischerweise nur noch wenige Tausend Argon2id-Hashes pro Sekunde. Die gleichen 208 Milliarden Kombinationen, die bei der Berechnung von SHA-256-Hashes weniger als eine Minute dauerten, benötigen nun Monate bis Jahre kontinuierlicher GPU-Zeit. Um den Angriff zu skalieren, muss ausreichend speicheräquivalente Hardware bereitgestellt werden, um viele Instanzen parallel auszuführen – was deutlich teurer ist als das Hinzufügen von GPU-Kernen. Diese Diskrepanz, nicht etwa ein Unterschied in der mathematischen Stärke, ist der eigentliche Grund für die Existenz speicherintensiver Algorithmen.

bcrypt erklärt: Stärken, Schwächen und Anwendungsbereiche

bcrypt wurde 1999 speziell für das Hashing von Passwörtern entwickelt. Es beinhaltet automatisches Salting und einen konfigurierbaren Kostenfaktor (auch Arbeitsfaktor genannt), der den Rechenaufwand des Hashings steuert. Ein höherer Kostenfaktor verlängert die benötigte Zeit pro Hash und bremst Angreifer aus, die Passwörter in großem Umfang knacken wollen.

Stärken:

• Eingebaute Salzung: bcrypt generiert und speichert automatisch ein eindeutiges Salt pro Passwort und beseitigt damit eine häufige Fehlerquelle für Entwickler.
• Adaptiver Kostenfaktor: Mit der Verbesserung der Hardware kann der Arbeitsfaktor erhöht werden, um die Widerstandsfähigkeit gegen Angriffe aufrechtzuerhalten.
• Kampferprobt: Über 25 Jahre eingehender Prüfung ohne Feststellung grundlegender Schwachstellen.
• Breite Unterstützung: Verfügbar in praktisch allen gängigen Programmiersprachen und Frameworks.

Einschränkungen:

• Maximal 72 Zeichen: bcrypt kürzt Eingaben, die länger als 72 Byte sind. Dies kann bei langen Passphrasen problematisch sein, wenn es nicht korrekt gehandhabt wird.
• Keine Speicherhärte: bcrypt benötigt keinen signifikanten Arbeitsspeicher, was es im Vergleich zu neueren Optionen anfälliger für hochgradig parallele Hardwareangriffe macht.

Argon2 vs. PBKDF2 vs. bcrypt: Wichtige Unterschiede

Nicht alle Passwort-Hashing-Algorithmen bieten das gleiche Schutzniveau. Hier ist ein Vergleich der drei wichtigsten Optionen hinsichtlich der entscheidenden Faktoren.

Funktion	bcrypt	argonxnumx	PBKDF2
Speicherhärte	Nicht speicherschwer	Speicherintensiv mit konfigurierbarer RAM-Nutzung	Nicht speicherschwer
Eingebaute Salzung	Ja, automatisch	Ja, automatisch	Nein, muss manuell bearbeitet werden.
Parallelitätskontrolle	Nicht unterstützt	Unterstützt durch Argon2id	Nicht unterstützt
Passwortlängenbeschränkung	Begrenzt auf 72 Bytes	Keine Beschränkung	Keine Beschränkung
NIST-empfohlen	Nicht aufgeführt in SP 800-63B	Ja	Ja
GPU-Widerstand	Moderat	Hoch	Niedrig bis mäßig
Reife	Über 25 Jahre	Verfügbar seit 2015	Verfügbar seit 2000

Argon2: Der moderne Standard

Argon2 gewann 2015 den Password Hashing Competition und wird vom NIST in SP 800-63B empfohlen. Es ist in drei Varianten verfügbar: Argon2d ist resistent gegen GPU-Angriffe, Argon2i gegen Seitenkanalangriffe und Argon2id kombiniert beides und ist die empfohlene Wahl für die meisten Passwortspeicherungsszenarien.

Argon2 zeichnet sich durch seinen hohen Speicherbedarf aus. Es benötigt während der Berechnung eine konfigurierbare Menge RAM. Dies verteuert parallele Angriffe auf spezialisierte Hardware wie ASICs oder FPGAs erheblich. Höhere Speicherkosten bedeuten weniger gleichzeitige Angriffsversuche, die ein Angreifer durchführen kann. Die aktuellen OWASP-Richtlinien empfehlen 46 MiB Speicher mit einer Iteration und einem Parallelisierungsgrad als bevorzugte Basiskonfiguration. Eine schlankere Konfiguration mit 19 MiB und zwei Iterationen ist eine akzeptable Alternative für speicherbeschränkte Umgebungen.

PBKDF2: Die Compliance-Option

PBKDF2 ist das älteste der drei Verfahren und wird in FIPS-validierten Umgebungen häufig eingesetzt, da es auf zugelassenen HMAC- Konstruktionen basiert. Wenn Ihre Organisation die Einhaltung von FIPS 140-2 oder 140-3 erfordert, was in Bundesbehörden und regulierten Finanzsektoren üblich ist, kann PBKDF2 mit SHA-256 oder SHA-512 erforderlich sein. Es ist nicht speicherresistent und daher das schwächste der drei Verfahren gegen Hardwareangriffe. Dies lässt sich durch eine hohe Anzahl von Iterationen kompensieren: Aktuelle Empfehlungen sehen mindestens 600,000 Iterationen mit HMAC-SHA-256 oder etwa 210,000 Iterationen mit dem rechenintensiveren HMAC-SHA-512 vor.

Welche Einschränkungen gibt es bei der Hash-basierten Passwortspeicherung?

• Hashing schützt zwar die gespeicherte Datenbank, bietet aber keinen Schutz vor Credential Stuffing, Phishing oder der Wiederverwendung von Passwörtern; ein korrekt gehashtes Passwort, das über eine Phishing-Seite gestohlen wurde, ist unabhängig vom Algorithmus kompromittiert.
• Die Stärke eines Algorithmus kann schwache Benutzerpasswörter nicht ausgleichen; ein häufig verwendetes Wort, das durch Argon2id geschützt ist, kann bei einem gezielten Wörterbuchangriff immer noch geknackt werden, nur langsamer als bei einem schnellen Hash.
• Eine Erhöhung des Speicherbedarfs oder der Iterationsanzahl führt zu einer erhöhten Nutzung serverseitiger Ressourcen beim Login. Daher ist die Parameteroptimierung ein echter Kompromiss bei der Kapazitätsplanung und keine kostenlose Sicherheitsverbesserung.
• Die Migration einer bestehenden Benutzerbasis auf einen neuen Algorithmus kann nicht sofort erfolgen, da alte Hashes nicht ohne das Klartextpasswort konvertiert werden können; die Migration muss schrittweise bei jedem erfolgreichen Login eines Benutzers erfolgen.

Welchen Algorithmus sollten Sie verwenden? Eine Entscheidungstabelle für Unternehmen

Szenario	Empfohlener Algorithmus	Empfohlene Parameter
Neue Anwendung, keine Altlasten	Argon2id	46 MiB Speicher, 1 Iteration, 1 Parallelisierungsgrad (OWASP-Baseline)
Das bestehende System verwendet bereits bcrypt.	bcrypt beibehalten, Migration planen	Kostenfaktor von mindestens 12; schrittweiser Neu-Hash zu Argon2id beim nächsten Login
FIPS 140-2/140-3 validierte Umgebung	PBKDF2-HMAC-SHA256	Mindestens 600,000 Iterationen, eindeutiges zufälliges Salt pro Passwort
Hochwertiges Ziel / erhöhtes Bedrohungsmodell	Argon2id, höhere Speicherkosten	64 MiB oder mehr, optimiert für akzeptable Anmeldeverzögerungen auf Ihrer Hardware
Ressourcenbeschränkt (mobil, eingebettet, serverlos)	Argon2id, schlankeres Profil	19 MiB Speicher, 2 Iterationen, 1 Parallelisierungsgrad

Bewährte Methoden zur sicheren Speicherung von Passwörtern

Die Wahl des richtigen Algorithmus ist nur der Anfang. Eine solide Implementierung sollte Folgendes beinhalten:

• Wählen Sie den richtigen Algorithmus: Verwenden Sie Argon2id für neue Systeme. Behalten Sie bcrypt für bestehende Systeme mit einem Kostenfaktor von 12 oder höher bei. Verwenden Sie PBKDF2 nur, wenn dies aufgrund von Compliance-Vorgaben erforderlich ist.
• Passen Sie Ihre Parameter an: Für Argon2id empfiehlt OWASP 46 MiB Arbeitsspeicher, 1 Iteration und 1 Parallelisierungsgrad als optimale Basiswerte. Passen Sie diese Werte entsprechend Ihrer Serverkapazität und akzeptablen Anmeldeverzögerung an.
• Verwenden Sie stets einzigartige, zufällige Salze: Auch wenn Ihre Bibliothek das Salting automatisch handhabt, sollten Sie sich dessen bewusst sein. Verwenden Sie niemals statische Werte oder sequentielle Bezeichner als Salts.
• Starke Passwörter erzwingen: Hashing ersetzt keine gute Passwortrichtlinie. Verlangen Sie Mindestlängen, weisen Sie bekannte unsichere Passwörter zurück und unterstützen Sie die Multi-Faktor-Authentifizierung.
• Separate Speicherung der Anmeldeinformationen: Speichern Sie Passwort-Hashes in einem separaten Speicher mit strengen Zugriffskontrollen. Anwendungen sollten nur zum Zeitpunkt der Authentifizierung auf Anmeldeinformationen zugreifen.
• Plan für die Algorithmenmigration: Konzipieren Sie Ihr System so, dass die Anmeldeinformationen beim nächsten Login neu gehasht werden. Dadurch können Sie Algorithmen oder Parameter aktualisieren, ohne eine Massen-Passwortzurücksetzung erzwingen zu müssen.

Wie Verschlüsselungsberatung helfen kann

Die korrekte Speicherung von Passwörtern ist eine Entscheidung im Bereich der kryptografischen Implementierung. Wie bei den meisten kryptografischen Entscheidungen können dabei leicht Fehler auftreten, die nicht sofort erkennbar sind. Ein falscher Algorithmus, ein fehlendes Salt, eine unzureichende Anzahl von Iterationen oder eine FIPS-inkompatible Implementierung können auf den ersten Blick unproblematisch erscheinen, Ihr Unternehmen aber unbemerkt ernsthaften Risiken aussetzen. Hier setzen die Verschlüsselungsberatungsdienste von Encryption Consulting an.

Unser Team unterstützt Unternehmen bei der Bewertung und Optimierung ihrer kryptografischen Implementierungen in Cloud-, On-Premise- und Hybridumgebungen. Ob Sie ein neues Authentifizierungssystem aufbauen, ein bestehendes überprüfen oder sich auf ein Compliance-Audit nach PCI-DSS, NIST SP 800-63B oder DSGVO vorbereiten – wir verfügen über das nötige Fachwissen, um den Ist-Zustand zu analysieren, und die praktische Erfahrung, um Ihnen bei der Behebung von Schwachstellen zu helfen.

Hier kommen unsere Beratungsleistungen im Bereich Verschlüsselung direkt zum Tragen, insbesondere im Hinblick auf die Sicherheit von Passwortspeicherung und Authentifizierung:

Überprüfung der kryptografischen Implementierung: Wir bewerten Ihre aktuelle Passwortspeicherung, einschließlich Algorithmuswahl, Salting-Verfahren, Parameteroptimierung sowie Trennung und Zugriffskontrolle der Anmeldeinformationen. So erhalten Sie ein klares Bild der Sicherheitslücken, bevor diese durch einen Sicherheitsvorfall oder eine Prüfung aufgedeckt werden.

Algorithmusauswahl und Migrationsplanung: Der Wechsel von bcrypt zu Argon2id oder von einer älteren PBKDF2-Implementierung zu einer, die den aktuellen NIST-Empfehlungen zur Iterationsanzahl entspricht, erfordert eine sorgfältige Planung, um bestehende Authentifizierungsabläufe nicht zu beeinträchtigen. Wir entwickeln Migrationspfade, die Anmeldeinformationen beim nächsten Login schrittweise neu hashen, ohne dass Passwörter erzwungen oder die Benutzer beeinträchtigt werden.

FIPS-Konformitätsausrichtung: Für Organisationen, die in einem föderalen oder regulierten Finanzumfeld tätig sind, in dem eine Validierung nach FIPS 140-2 oder 140-3 erforderlich ist, helfen wir Ihnen bei der Auswahl und Konfiguration von PBKDF2-Implementierungen, die die Konformitätsanforderungen erfüllen und gleichzeitig die geringere Hardwareresistenz des Algorithmus durch eine geeignete Parameterkonfiguration kompensieren.

Compliance-Gap-Analyse: Rahmenwerke wie PCI-DSS, DSGVO und NIST SP 800-63B stellen Anforderungen an den Schutz von Authentifizierungsdaten. Wir vergleichen Ihre aktuelle Implementierung mit diesen Anforderungen, identifizieren Lücken und erstellen einen klaren Fahrplan zur Behebung der Mängel.

Unsachgemäße Passwortverwaltung zählt zu den häufigsten und am besten vermeidbaren Sicherheitslücken. Falls Ihre Organisation ihre Vorgehensweise beim Umgang mit Zugangsdaten noch nicht formell überprüft hat, ist jetzt der richtige Zeitpunkt dafür.

Fazit

Die Speicherung von Passwörtern ist zwar kein glamouröses Thema, aber von grundlegender Bedeutung. Die Entscheidungen auf Datenebene entscheiden darüber, ob ein Sicherheitsvorfall begrenzt bleibt oder sich zu einem viel größeren Problem ausweitet. Jede andere Sicherheitsmaßnahme in einer Anwendung hängt letztendlich davon ab, wie Anmeldeinformationen gespeichert werden. Angesichts der Häufigkeit, mit der Passwörter wiederverwendet werden, reichen die Folgen einer mangelhaften Implementierung oft weit über die ursprüngliche Anwendung hinaus.

Das Tückische an diesem Bereich ist, dass die Folgen selten sichtbar werden, bis etwas schiefgeht. Eine ungeeignete Hash-Methode beeinträchtigt die Performance nicht und löst keine Warnmeldungen aus. Sie bleibt unbemerkt im Produktivbetrieb, bis es zu einem Sicherheitsvorfall kommt und Angreifer die gespeicherten Hashwerte entschlüsseln. Die gute Nachricht: Die Richtlinien sind eindeutig. Das NIST hat klare Empfehlungen veröffentlicht, und in allen gängigen Programmiersprachen existieren ausgereifte Bibliotheken zur korrekten Implementierung dieser Algorithmen.

Der Weg nach vorn ist klar. Verwenden Sie Argon2id für neue Implementierungen. Pflegen Sie bcrypt verantwortungsvoll für bestehende Systeme mit einem Kostenfaktor von mindestens 12. Greifen Sie nur dann auf PBKDF2 zurück, wenn dies aus Compliance-Gründen erforderlich ist, und kompensieren Sie dies mit einer hohen Iterationszahl. Verwenden Sie stets ein Salt, optimieren Sie Ihre Parameter und planen Sie zukünftige Algorithmusmigrationen von Anfang an ein. Betrachten Sie dies als fortlaufende Praxis, nicht als einmalige Einrichtung.

Häufig gestellte Fragen

Welchen Passwort-Hashing-Algorithmus sollte ein neues Projekt verwenden?

Argon2id verwendet die aktuellen OWASP-Standardvorgaben von 46 MiB Speicher, 1 Iteration und 1 Grad Parallelität. Es ist speicherintensiv, wird vom NIST empfohlen und hat praktisch keine Beschränkung der Passwortlänge.

Ist die Verwendung von bcrypt noch sicher?

Ja, mit einem Kostenfaktor von mindestens 12. bcrypt wurde über 25 Jahre lang geprüft, ohne dass es zu grundlegenden Fehlern gekommen ist, aber es mangelt an Speichersicherheit, daher sollten neue Systeme Argon2id bevorzugen, sofern keine Legacy-Beschränkungen bestehen.

Warum kann das Salzen allein schnelle, gewaltsame Angriffe nicht verhindern?

Durch das Hinzufügen eines Salts werden vorab berechnete Rainbow-Tabellen überlistet, da jeder Hashwert eindeutig ist. Die Berechnung des Hashwerts selbst wird dadurch jedoch nicht verlangsamt. Eine schnelle Hashfunktion ohne Salt, wie beispielsweise SHA-256, kann selbst mit einem eindeutigen Salt pro Passwort schnell per Brute-Force geknackt werden; nur ein bewusst langsamer, speicherintensiver Algorithmus widersteht dieser Gefahr.

Wann ist PBKDF2 die richtige Wahl anstelle von Argon2id?

Wenn die Validierung nach FIPS 140-2 oder 140-3 zwingend erforderlich ist, da PBKDF2 auf zugelassenen HMAC-Konstruktionen basiert, Argon2 dies derzeit nicht tut, sollte die mangelnde Speichersicherheit durch mindestens 600,000 Iterationen von HMAC-SHA-256 kompensiert werden.

Wie sollte eine Organisation von einem älteren Algorithmus auf Argon2id umsteigen?

Bei jedem erfolgreichen Login eines Benutzers wird schrittweise der alte Hashwert überprüft, das Passwort anschließend mit Argon2id neu gehasht und der neue Hashwert gespeichert. Dadurch wird ein erzwungener Massen-Passwortreset vermieden und die Migration nach und nach abgeschlossen.

Referenzen

• Spickzettel zur OWASP-Passwortspeicherung
• NIST SP 800-63B, Richtlinien für digitale Identität