Wer heute eine Datenbank mit Nutzerpasswörtern verschlüsselt, hat die Wahl zwischen drei etablierten Kandidaten: PBKDF2, scrypt und Argon2id. Alle drei lösen dasselbe Grundproblem, nämlich ein Passwort so in einen Hash zu verwandeln, dass ein Angreifer mit gestohlener Datenbank möglichst lange braucht, um die Klartexte zurückzurechnen. Doch die drei Verfahren unterscheiden sich fundamental darin, wie teuer sie einen Angriff auf spezialisierter Hardware machen. Die OWASP Password Storage Cheat Sheet, aktualisiert am 5. Oktober 2026, empfiehlt für neue Systeme klar Argon2id, erlaubt scrypt als Alternative und PBKDF2 nur noch für Umgebungen mit FIPS-140-Zwang. Dieser Vergleich zeigt, was die drei Algorithmen technisch unterscheidet, welche Parameter OWASP, NIST und die IETF aktuell vorschreiben, wer sie in der Praxis einsetzt und wie der Wechsel auf ein moderneres Verfahren gelingt.

Der Unterschied ist kein akademisches Detail. Als LastPass im Dezember 2022 einen Einbruch in verschlüsselte Tresordaten bestätigte, rückte die Diskussion um Iterationszahlen und Speicherhärte schlagartig aus Fachkreisen in die breite Öffentlichkeit. Seitdem fragen sich viele Entwicklerteams, ob ihre eigene PBKDF2-Konfiguration noch zeitgemäß ist oder ob ein Wechsel zu scrypt oder Argon2id längst überfällig wäre. Dieser Artikel beantwortet genau das, mit Zahlen aus den aktuellen Standarddokumenten und mit echten Beispielen aus Django, Bitwarden, 1Password, WordPress und Ubuntu.

Dabei geht es nicht nur um die Wahl zwischen drei Namen in einer Konfigurationsdatei. Wer eine Datenbank mit Millionen Nutzerkonten betreibt, trifft mit dieser Entscheidung eine Risikoabwägung, die über Jahre Bestand haben muss, selbst wenn sich Angriffshardware und Cloud-Rechenkapazität in diesem Zeitraum spürbar weiterentwickeln. Ein zu schwach konfigurierter Hash fällt im Zweifel erst auf, wenn eine Datenbank bereits kompromittiert und veröffentlicht wurde, dann ist es für eine nachträgliche Korrektur zu spät. Genau deshalb lohnt sich der genaue Blick auf Parameter, Standards und reale Produktionsbeispiele, bevor die eigene Entscheidung getroffen wird.

PBKDF2 erklärt: Der Veteran unter Druck

PBKDF2 (Password-Based Key Derivation Function 2) stammt aus dem Jahr 2000 und wurde ursprünglich in RFC 2898 standardisiert. Das Verfahren nimmt ein Passwort, einen Salt und eine Iterationszahl und wendet eine Hashfunktion wie HMAC-SHA256 oder HMAC-SHA512 wiederholt an. Jede zusätzliche Iteration macht einen Brute-Force-Versuch teurer, weil der Rechenaufwand linear mit der Iterationszahl wächst. Genau das war 2000 ein kluger Kompromiss, weil Prozessoren damals der einzige relevante Angriffsvektor waren.

Das Problem von PBKDF2 liegt nicht in seiner mathematischen Konstruktion, sondern in seinem Ressourcenprofil. Die Funktion verbraucht praktisch keinen Arbeitsspeicher. Ein Angreifer kann deshalb Tausende Instanzen parallel auf einer Grafikkarte oder einem FPGA laufen lassen, ohne dass sich die Einheiten gegenseitig ausbremsen. Laut OWASP-Cheat-Sheet, aktualisiert am 5. Oktober 2026, verlangt eine sichere PBKDF2-HMAC-SHA256-Implementierung inzwischen mindestens 600.000 Iterationen, bei PBKDF2-HMAC-SHA512 reichen laut derselben Quelle 210.000 Iterationen. Das klingt nach einer hohen Hürde, lässt sich aber auf moderner GPU-Hardware durch schlichte Parallelisierung in großem Umfang kompensieren, weil jede einzelne Iteration kaum Speicherzugriffe benötigt.

Trotzdem ist PBKDF2 nicht tot. Der Algorithmus bleibt der einzige der drei Kandidaten, für den FIPS-140-validierte kryptografische Module in großer Zahl existieren. Wer ein Produkt für US-Behörden, Finanzdienstleister oder andere regulierte Branchen baut, kommt an dieser Validierungspflicht oft nicht vorbei. Genau deshalb hält sich PBKDF2 in Systemen wie Django, 1Password und Bitwarden als Standard, selbst wenn die Entwicklerteams dort technisch bessere Alternativen kennen. Die Kombination aus langer Praxiserfahrung, breiter Bibliotheksunterstützung und Compliance-Tauglichkeit erklärt, warum PBKDF2 25 Jahre nach seiner Einführung immer noch produktiv läuft, auch wenn es im direkten GPU-Widerstandsvergleich das schwächste der drei Verfahren ist.

Ein weiterer Grund für die Langlebigkeit von PBKDF2 liegt in seiner Einfachheit. Die Funktion lässt sich mit wenigen Zeilen Code aus praktisch jeder Kryptobibliothek aufrufen, von OpenSSL über die .NET-Basisklassen bis zu den Standardmodulen in Python, Java und Node.js. Diese Allgegenwart macht PBKDF2 zur sicheren Rückfalloption, wenn ein Projekt in mehreren Sprachumgebungen gleichzeitig läuft und ein identisches Hashing-Verhalten über alle Plattformen hinweg garantiert werden muss. Wer dagegen vor allem GPU-Resistenz priorisiert und keine Compliance-Zwänge hat, zahlt mit PBKDF2 einen Sicherheitspreis, den die beiden anderen Verfahren nicht verlangen.

scrypt erklärt: Speicherhärte gegen GPU-Farmen

scrypt entstand 2009, entwickelt von Colin Percival ursprünglich für das Backup-Tool Tarsnap. Die Kernidee: Ein Hashing-Verfahren soll nicht nur Rechenzeit, sondern auch Arbeitsspeicher verschlingen. Während PBKDF2 nur einen Kostenfaktor kennt, arbeitet scrypt mit drei Parametern gleichzeitig, nämlich dem CPU-/Speicherkostenfaktor N, der Blockgröße r und dem Parallelitätsgrad p. Diese Kombination zwingt einen Angreifer dazu, für jede parallele Rateversuch-Instanz einen eigenen, oft mehrere hundert Megabyte großen Speicherblock zu reservieren.

Genau das macht spezialisierte Angriffshardware deutlich unattraktiver. Eine GPU hat zwar tausende Rechenkerne, aber begrenzten und geteilten Speicher pro Kern. Wenn jede Hash-Berechnung einen eigenen Speicherblock von vielen Megabyte braucht, sinkt die Zahl der gleichzeitig möglichen Parallelberechnungen drastisch, selbst auf teurer Hardware. Laut OWASP-Cheat-Sheet, aktualisiert am 5. Oktober 2026, empfiehlt die Organisation für scrypt mindestens die Parameter N=2^17, r=8 und p=1, was rund 128 MiB Arbeitsspeicher pro Hash-Vorgang bedeutet. Als gestufte Alternativen nennt OWASP auch N=2^16 mit p=2, N=2^15 mit p=3, N=2^14 mit p=5 oder N=2^13 mit p=10, jeweils mit r=8.

scrypt wird heute vor allem dort eingesetzt, wo Argon2id aus Kompatibilitätsgründen fehlt, aber trotzdem ein speicherhartes Verfahren verlangt wird. Bitcoin-nahe Projekte und einige Kryptowährungen mit Proof-of-Work-Mining nutzten scrypt-Varianten bereits früh, weil der hohe Speicherbedarf spezialisierte ASIC-Hardware erschwert, wenn auch nicht unmöglich macht. Im Kontext von Passwort-Hashing für Webanwendungen gilt scrypt als solide zweite Wahl, wenn eine Argon2id-Implementierung aus Plattformgründen nicht zur Verfügung steht, etwa in älteren Sprachumgebungen oder bei eingeschränkten Paketquellen in Unternehmensnetzwerken.

Ein praktischer Nachteil von scrypt gegenüber Argon2id zeigt sich bei der Feinsteuerung. Weil Speicherkosten und Rechenaufwand über denselben Parameter N gekoppelt sind, lässt sich bei scrypt schwerer unabhängig regeln, ob mehr Speicher oder mehr Rechenzeit investiert werden soll. Argon2id trennt diese beiden Stellschrauben bewusst, was Entwicklerteams mehr Kontrolle gibt, wenn sie ihre Serverhardware exakt auf die erwartete Login-Last abstimmen wollen. Für Teams, die bereits erfolgreich mit scrypt arbeiten und keine akuten Probleme erkennen, besteht trotzdem kein zwingender Handlungsdruck, da scrypt nach wie vor zu den von OWASP anerkannten, speicherharten Verfahren gehört.

Argon2id erklärt: Der amtierende Standard

Argon2 gewann 2015 die Password Hashing Competition, einen offenen Wettbewerb unter Kryptografen zur Suche nach dem Nachfolger von bcrypt und PBKDF2. Aus dem Wettbewerb gingen drei Varianten hervor: Argon2d, optimiert gegen GPU-Angriffe, Argon2i, resistent gegen Seitenkanalangriffe, und Argon2id als hybride Mischform. Genau diese hybride Variante empfiehlt OWASP heute als Standardwahl, weil sie die GPU-Resistenz von Argon2d mit dem Seitenkanalschutz von Argon2i kombiniert.

Argon2id trennt seine Kostenparameter klarer als scrypt: Speicherbedarf m, Anzahl der Iterationen t und Parallelitätsgrad p lassen sich unabhängig voneinander einstellen. Laut OWASP-Cheat-Sheet, aktualisiert am 5. Oktober 2026, lautet die Mindestkonfiguration m=19.456 KiB, t=2 und p=1, also knapp 19 MiB Speicher bei zwei Durchläufen. Als Alternativen nennt OWASP unter anderem 46 MiB bei t=1, 12 MiB bei t=3, 9 MiB bei t=4 oder 7 MiB bei t=5, jeweils mit p=1. Diese Flexibilität erlaubt es Entwicklerteams, den Speicherbedarf gezielt an die eigene Serverinfrastruktur anzupassen, ohne auf die grundsätzliche Speicherhärte zu verzichten.

Ein aktueller IETF-Entwurf, draft-ietf-kitten-password-storage, zuletzt aktualisiert am 16. Oktober 2026, geht für ein Mindestprofil sogar deutlich weiter und setzt m=2 GiB, t=2, p=1 und eine Ausgabelänge von mindestens 32 Byte an. Diese Diskrepanz zwischen OWASP und dem IETF-Entwurf zeigt, dass es keinen einzigen “richtigen” Parametersatz gibt, sondern eine Bandbreite, die von der verfügbaren Serverhardware und dem Bedrohungsmodell abhängt. Wer Login-Spitzen mit zehntausenden gleichzeitigen Anfragen erwartet, wird kaum 2 GiB Speicher pro Hash-Vorgang reservieren können, während ein kleinerer Dienst mit wenigen hundert Logins pro Minute davon profitiert.

Technische Spezifikationen im direkten Vergleich

Die folgende Tabelle fasst die wichtigsten technischen Eigenschaften aller drei Verfahren zusammen, basierend auf dem OWASP Password Storage Cheat Sheet, dem IETF-Entwurf draft-ietf-kitten-password-storage und öffentlich dokumentierten Implementierungsdetails.

MerkmalPBKDF2scryptArgon2id
Erstveröffentlichung2000 (RFC 2898)20092015
Entwickler / GremiumRSA LaboratoriesColin PercivalPassword Hashing Competition
SpeicherhärteKeineHoch (CPU + Speicher gekoppelt)Hoch (Speicher separat einstellbar)
OWASP-Minimum 2026600.000 Iterationen (SHA256)N=2^17, r=8, p=1 (≈128 MiB)m=19.456 KiB, t=2, p=1 (≈19 MiB)
IETF-Entwurfsminimum600.000 Iterationen (SHA256)N=131.072, r=8, p=1m=2 GiB, t=2, p=1
NIST SP 800-63B-4 StatusAusdrücklich zugelassenIn Zusammenfassungen gelistetNicht in jeder Zusammenfassung ausdrücklich genannt
FIPS-140-ValidierungBreit verfügbarSelten validiertPraktisch nicht validiert
Parallelisierbarkeit auf GPUHoch (wenig Speicher pro Thread)Niedrig bis mittelNiedrig
Parameteranzahl1 (Iterationen)3 (N, r, p)3 (m, t, p), getrennt steuerbar
Typischer Praxiswert (Bitwarden, 1Password)600.000 Iterationen StandardAls Option selten StandardAls Nutzeroption verfügbar
Sprach-/Framework-UnterstützungSehr breit (fast jede Sprache)Breit, aber seltener StandardWachsend, benötigt oft Zusatzpaket
Empfehlungsstatus OWASP 2026Nur bei FIPS-ZwangAlternative, wenn Argon2id fehltErste Wahl für neue Systeme

Auffällig ist die Parameterlücke zwischen OWASP und dem IETF-Entwurf bei Argon2id: 19 MiB gegenüber 2 GiB liegen um den Faktor 100 auseinander. Beide Werte sind gültige, aktuell diskutierte Empfehlungen, was zeigt, wie stark die Einschätzung “sicher genug” von der jeweiligen Risikoabwägung abhängt. Ein Vergleich der rohen Speicherzahlen zwischen scrypt und Argon2id ist außerdem nicht direkt gleichbedeutend mit identischer Sicherheit, weil beide Algorithmen unterschiedliche interne Speicherzugriffsmuster verwenden, wie OWASP selbst anmerkt.

OWASP, NIST und IETF im Vergleich: Drei Standards, ein Trend

Statt auf einzelne, oft nicht herstellerunabhängig verifizierte GPU-Benchmarks zu setzen, lohnt sich ein Blick auf die drei maßgeblichen Standarddokumente, die 2026 über Passwort-Hashing entscheiden: das OWASP Password Storage Cheat Sheet, NIST SP 800-63B-4 und den aktuellen IETF-Entwurf der Kitten-Arbeitsgruppe. Alle drei kommen aus unterschiedlichen Traditionen, Anwendungssicherheit, föderale Identitätsrichtlinien und Internet-Protokollstandardisierung, und doch zeigen sie einen gemeinsamen Trend: weg von reinen Iterationszählern, hin zu expliziter Speicherhärte.

NIST SP 800-63B-4 wurde laut verfügbaren Quellen am 31. Juli 2025 final veröffentlicht und verlangt für gespeicherte Passwörter eine geeignete, kostenintensive Hashfunktion, einen individuellen Salt pro Passwort und einen möglichst hohen, praktisch vertretbaren Kostenfaktor. Eine Zusammenfassung der Richtlinie listet bcrypt, scrypt, PBKDF2 und Balloon Hashing als akzeptierte Verfahren, wobei Argon2id in dieser Zusammenfassung nicht ausdrücklich separat aufgeführt wird. Das bedeutet nicht, dass NIST Argon2id ablehnt, sondern eher, dass die Richtlinie allgemeine Anforderungen an Kostenfaktoren formuliert, anstatt eine feste Algorithmenliste vorzuschreiben.

Der IETF-Entwurf draft-ietf-kitten-password-storage geht hier technisch am weitesten, weil er konkrete Mindestprofile für alle drei Verfahren nennt und dabei bewusst konservativ kalkuliert. Für PBKDF2-HMAC-SHA256 verlangt die zuletzt am 12. Oktober 2026 aktualisierte Fassung mindestens 600.000 Iterationen, für scrypt N=131.072 mit r=8 und p=1, und für Argon2id die bereits erwähnten 2 GiB Speicher bei t=2. OWASP wiederum bleibt bei seinen praxisnäheren 19-MiB- und 128-MiB-Werten, weil die Organisation explizit auf die Server-Realität vieler Webanwendungen Rücksicht nimmt, die nicht unbegrenzt Arbeitsspeicher pro Login-Vorgang reservieren können. Für Entwicklerteams heißt das: Wer sich strikt an IETF-Zahlen orientiert, baut mehr Sicherheitsmarge ein, muss dafür aber auch deutlich mehr Serverkapazität einplanen.

Interessant ist außerdem, wie sich die drei Gremien in ihrer Rolle unterscheiden. OWASP richtet sich primär an Anwendungsentwickler und formuliert deshalb Empfehlungen, die sich direkt in Code übersetzen lassen, mit konkreten Parameterwerten für gängige Bibliotheken. NIST SP 800-63B-4 adressiert vor allem US-Bundesbehörden und Auftragnehmer, weshalb die Richtlinie allgemeiner formuliert ist und bewusst Spielraum für unterschiedliche Implementierungen lässt. Der IETF-Entwurf wiederum zielt auf Interoperabilität zwischen Systemen verschiedener Hersteller ab und kalkuliert deshalb mit höherer Sicherheitsmarge, weil ein über viele Jahre gültiger Internetstandard Hardware-Fortschritte über einen längeren Zeitraum vorwegnehmen muss als eine Web-Anwendungsrichtlinie, die sich leichter aktualisieren lässt. Wer diese unterschiedlichen Zielgruppen versteht, kann besser einschätzen, warum die drei Dokumente zu teils stark abweichenden Zahlen kommen, ohne dass eines der Dokumente deshalb falsch liegt.

Ressourcenbedarf und Betriebskosten in der Praxis

Alle drei Algorithmen sind offene, lizenzkostenfreie Verfahren, die in Standardbibliotheken fast jeder Programmiersprache verfügbar sind. Der eigentliche Kostentreiber liegt deshalb nicht in Lizenzgebühren, sondern in der benötigten Serverinfrastruktur, dem Integrationsaufwand und möglichen Compliance-Anforderungen. Die folgende Tabelle ordnet die drei Verfahren nach diesen praxisrelevanten Kostenfaktoren ein.

KostenfaktorPBKDF2scryptArgon2id
Lizenzkosten0 € (offen)0 € (offen)0 € (offen)
RAM pro Login (OWASP-Minimum)Minimal≈128 MiB≈19 MiB
Skalierungskosten bei Login-SpitzenNiedrigHoch bei vielen parallelen LoginsMittel, je nach gewähltem Profil
FIPS-140-ZertifizierungskostenMeist vorhandene Module nutzbarZusätzliche Validierung nötigPraktisch keine validierten Module
Integrationsaufwand für EntwicklerSehr geringGering bis mittelMittel, oft Zusatzpaket nötig
Nativ in StandardbibliothekJa (fast überall)TeilweiseTeilweise, wächst 2026
Rehash-Aufwand bei MigrationEntfällt (Ausgangspunkt)MittelMittel, meist per Login-Rehash
Geeignet für Shared Hosting mit wenig RAMJaEingeschränktEingeschränkt bis bedingt

Der auffälligste Posten ist die Skalierungsfrage bei Login-Spitzen. Ein Dienst mit zehntausend gleichzeitigen Anmeldeversuchen, etwa während einer Marketingkampagne oder nach einem erzwungenen Passwort-Reset, muss bei Argon2id mit 19 MiB oder bei scrypt mit 128 MiB pro aktivem Login-Vorgang rechnen. Multipliziert mit der erwarteten Lastspitze ergibt sich schnell ein zusätzlicher Arbeitsspeicherbedarf im Gigabyte-Bereich, der in die Serverkapazitätsplanung einfließen muss. Teams, die das unterschätzen, laufen Gefahr, ihre eigene Login-Infrastruktur durch die Hashing-Last selbst in die Knie zu zwingen, ein Risiko, das in der Sicherheitsbranche oft als “hashing-induzierter Denial of Service” bezeichnet wird.

Bedrohungsmodell: Offline-Angriffe gegen Online-Angriffe

Die Wahl zwischen PBKDF2, scrypt und Argon2id betrifft fast ausschließlich ein bestimmtes Angriffsszenario: den Offline-Angriff nach einem Datenbankdiebstahl. Hat ein Angreifer erst einmal eine Kopie der Hash-Tabelle, kann er beliebig viele Rateversuche auf eigener Hardware durchführen, ohne von Ratenbegrenzung, Captchas oder Konto-Sperrungen gebremst zu werden. Genau in diesem Szenario entfaltet sich der Unterschied zwischen einem Verfahren ohne Speicherhärte und einem mit Speicherhärte in vollem Umfang, weil die verfügbare Rateversuchsgeschwindigkeit nur noch von der eigenen Hardware des Angreifers begrenzt wird.

Beim Online-Angriff, also dem direkten Ausprobieren von Passwörtern über das normale Login-Formular, spielt der Hashing-Algorithmus dagegen eine kleinere Rolle. Hier greifen andere Schutzmechanismen wie Ratenbegrenzung pro IP-Adresse, Konto-Sperrung nach mehreren Fehlversuchen, Captchas und die Überwachung ungewöhnlicher Login-Muster. Ein Team, das ausschließlich in Online-Angriffsszenarien denkt, unterschätzt leicht, wie wichtig die Offline-Resistenz ist, denn fast jede große Datenpanne der vergangenen Jahre, von Sony über Adobe bis zu LinkedIn, begann mit dem Diebstahl einer kompletten Datenbank und endete mit tagelangem bis monatelangem Offline-Cracking der erbeuteten Hashes.

Für die Praxis bedeutet das: Ratenbegrenzung und starke Hashing-Verfahren ergänzen sich, ersetzen sich aber nicht gegenseitig. Ein Dienst mit perfekter Online-Ratenbegrenzung, aber schwachem PBKDF2 mit niedriger Iterationszahl bleibt bei einem erfolgreichen Datenbankdiebstahl verwundbar. Umgekehrt schützt auch das stärkste Argon2id-Profil nicht vor einem Angreifer, der durch fehlende Ratenbegrenzung Millionen Login-Versuche direkt über die Anwendung selbst durchführen kann. Beide Schutzschichten gehören deshalb in jedes ernstzunehmende Sicherheitskonzept, unabhängig davon, welcher der drei Algorithmen am Ende zum Einsatz kommt.

Häufige Implementierungsfehler bei allen drei Verfahren

Ein starker Algorithmus allein garantiert keine sichere Implementierung. In der Praxis entstehen die größten Schwachstellen nicht durch die Wahl von PBKDF2 statt Argon2id, sondern durch Fehler bei der konkreten Umsetzung. Der häufigste Fehler ist ein fest im Quellcode hinterlegter, für alle Nutzer identischer Salt, statt für jedes Passwort einen eigenen, zufälligen Salt zu erzeugen. Ein globaler Salt macht vorberechnete Angriffstabellen zwar etwas teurer zu erstellen, hebt aber den eigentlichen Schutzzweck des Salts weitgehend auf, sobald der Angreifer den festen Wert kennt oder errät.

Ein zweiter verbreiteter Fehler ist das Kopieren veralteter Parameter aus Tutorials oder Stack-Overflow-Antworten, die teils noch aus den frühen 2010er-Jahren stammen und damals übliche, heute viel zu niedrige Iterationszahlen oder Speicherwerte enthalten. Wer Code-Beispiele aus älteren Quellen übernimmt, sollte die enthaltenen Parameter immer gegen die aktuellen OWASP-Empfehlungen prüfen, statt sie unverändert zu übernehmen. Ein dritter Fehler betrifft die Verifikationslogik: Manche Implementierungen vergleichen den berechneten Hash mit einem einfachen String-Vergleich, der je nach Programmiersprache nicht konstant in der Laufzeit ist und dadurch theoretisch Timing-Angriffe ermöglicht. Die korrekte Lösung ist ein zeitkonstanter Vergleich, wie ihn praktisch alle etablierten Hashing-Bibliotheken bereits mitliefern.

Ein letzter, oft unterschätzter Fehler betrifft die fehlende Parameterpflege über Zeit. Ein Team, das heute die OWASP-Minimumwerte korrekt implementiert, aber die Konfiguration nie wieder anfasst, gerät in genau die Situation, die den LastPass-Vorfall mitprägte: Werte, die bei der Einführung angemessen waren, veralten durch steigende Hardware-Leistung schleichend. Ein tragfähiger Ansatz speichert deshalb die verwendeten Parameter zusammen mit jedem Hash in der Datenbank und erlaubt einen schrittweisen Rehash bei Login, sobald neue, höhere Zielwerte definiert werden, ohne dass Nutzer dafür aktiv ihr Passwort ändern müssen.

Real-World-Einsatz 2026: Wer nutzt was

Theorie und Standardempfehlung sind eine Sache, die tatsächliche Wahl großer Plattformen eine andere. Ein Blick auf sechs konkrete, öffentlich dokumentierte Fälle zeigt, wie unterschiedlich die drei Verfahren 2026 tatsächlich eingesetzt werden. Die Beispiele reichen von Webframeworks über Passwortmanager bis zum Betriebssystem-Unterbau und zeigen, dass es keine einzige, branchenweit einheitliche Antwort gibt, sondern eine Reihe gut begründeter, aber unterschiedlicher Entscheidungen je nach Zielgruppe und technischer Ausgangslage.

Django: PBKDF2 bleibt Standard, Argon2 optional

Laut der offiziellen Django-Dokumentation verwendet das Framework für neu erstellte Passwörter standardmäßig den ersten Eintrag der Einstellung PASSWORD_HASHERS, und das ist seit Jahren PBKDF2 mit SHA256. Argon2 lässt sich aktivieren, erfordert aber die Installation des Zusatzpakets argon2-cffi und das Voranstellen von Argon2PasswordHasher in der Konfiguration. Wichtig ist der Unterschied zwischen “unterstützt” und “Standard”: Django kann Argon2- und bcrypt-Hashes verifizieren, erzeugt neue Passwörter aber weiterhin per PBKDF2, solange niemand die Konfiguration aktiv ändert.

Bitwarden und 1Password: PBKDF2 als Basis, Argon2id als Option

Das Bitwarden Security Whitepaper dokumentiert, dass neu erstellte Konten standardmäßig PBKDF2-SHA256 mit 600.000 Iterationen nutzen, wobei die E-Mail-Adresse der Nutzer als Salt dient. Nutzer können den KDF nach der Kontoerstellung manuell auf Argon2id umstellen. 1Password setzt laut seinem offiziellen Whitepaper ebenfalls auf PBKDF2-HMAC-SHA256 für die Ableitung des normalisierten Kontopassworts. Beide Passwortmanager zeigen damit ein Muster, das in der Branche häufig vorkommt: PBKDF2 als breit kompatibler Standard, Argon2id als Option für sicherheitsbewusste Nutzer, die die höhere Serverlast in Kauf nehmen.

WordPress 6.8: Abschied von phpass, Umstieg auf bcrypt

Ein besonders aufschlussreiches Beispiel liefert WordPress. Laut der offiziellen Ankündigung auf make.wordpress.org vom 17. Februar 2025 wechselte WordPress 6.8 bei neu gesetzten Passwörtern vom jahrzehntealten, portablen phpass-Verfahren zu bcrypt, umgesetzt über die native PHP-Funktion password_hash() mit vorgeschaltetem SHA-384-Hash. Bestehende phpass- oder MD5-kompatible Hashes bleiben für die Anmeldung gültig und werden bei Gelegenheit automatisch neu gehasht. Über den Filter wp_hash_password_algorithm lässt sich zusätzlich PASSWORD_ARGON2ID aktivieren, wenn der Server das unterstützt, Argon2id ist damit für Millionen von WordPress-Installationen erreichbar, aber nicht der dokumentierte Standard.

Ubuntu: yescrypt löst SHA-512 im Systemlogin ab

Auch außerhalb von Webanwendungen bewegt sich der Markt. Die offizielle Ubuntu-Sicherheitsdokumentation listet, dass Ubuntu 14.04 bis 20.04 für lokale Systemkonten noch SHA-512 zur Passwort-Hashing nutzte, während Ubuntu 22.04, 24.04, 25.04 und 25.10 auf yescrypt umgestellt haben, ein weiteres speicherhartes Verfahren, das denselben Grundgedanken wie scrypt und Argon2id verfolgt. Dieser Schritt bei einer der meistgenutzten Linux-Distributionen zeigt, dass der Umstieg auf speicherharte Hashfunktionen längst nicht mehr nur eine Empfehlung für Webentwickler ist, sondern auch tief im Betriebssystem-Unterbau ankommt.

Die LastPass-Lektion: Wenn der Iterationswert zu niedrig ist

Kein Fall zeigt die praktische Relevanz der Iterationszahl so deutlich wie LastPass. In der offiziellen “Notice of Security Incident” vom 22. Dezember 2022 bestätigte das Unternehmen, dass verschlüsselte Tresordaten von Kunden bei einem Einbruch in eine Cloud-Backup-Umgebung kopiert wurden. Für die Ableitung des Master-Passwort-Schlüssels gab LastPass zu diesem Zeitpunkt offiziell 100.100 PBKDF2-Iterationen an.

Der Vorfall löste eine breite Debatte darüber aus, wie lange ein Anbieter einen einmal gesetzten Iterationswert unverändert lässt, während sich die verfügbare Angriffshardware weiterentwickelt. Eine Zahl, die bei der Einführung als ausreichend galt, kann wenige Jahre später bereits spürbar schwächer wirken, einfach weil GPU-Rechenleistung pro Euro kontinuierlich steigt. Genau das ist der Kernunterschied zwischen reinen Iterationsverfahren wie PBKDF2 und speicherharten Verfahren wie Argon2id: Speicherhärte bremst den Fortschritt von GPU-Angriffen strukturell stärker, weil Speicherkapazität pro Chip langsamer wächst als reine Rechenleistung. Der LastPass-Fall ist deshalb weniger ein Beleg dafür, dass PBKDF2 grundsätzlich unsicher ist, sondern ein Beispiel dafür, wie wichtig es ist, Iterationszahlen und Parameter regelmäßig an aktuelle Hardware anzupassen, unabhängig vom gewählten Algorithmus.

Vor- und Nachteile aller drei Algorithmen

Nach der technischen Einordnung folgt hier die kompakte Gegenüberstellung der wichtigsten Argumente für und gegen jeden der drei Algorithmen. Die Punkte fassen zusammen, was in den vorherigen Abschnitten im Detail erklärt wurde, und eignen sich als schnelle Checkliste für die eigene Entscheidung.

PBKDF2: Vorteile und Nachteile

  • Vorteil: Breiteste Sprach- und Bibliotheksunterstützung aller drei Verfahren
  • Vorteil: FIPS-140-validierte Module gut verfügbar, wichtig für Behörden und Finanzsektor
  • Vorteil: Geringer Speicherbedarf, läuft auch auf stark eingeschränkten Servern
  • Nachteil: Keine Speicherhärte, dadurch am leichtesten auf GPUs zu parallelisieren
  • Nachteil: Muss mit sehr hohen Iterationszahlen kompensiert werden, was die CPU-Last erhöht
  • Nachteil: Gilt laut OWASP 2026 nur noch als zweite Wahl außerhalb von Compliance-Zwängen

scrypt: Vorteile und Nachteile

  • Vorteil: Deutliche Speicherhärte erschwert GPU- und ASIC-Angriffe spürbar
  • Vorteil: Seit 2009 praxiserprobt, unter anderem in Kryptowährungsprojekten
  • Vorteil: Gute Alternative, wenn Argon2id auf der Zielplattform fehlt
  • Nachteil: Nur ein gekoppelter Kostenparameter N statt getrennter Steuerung
  • Nachteil: Seltener nativ in Standardbibliotheken enthalten als PBKDF2
  • Nachteil: Kaum FIPS-140-validierte Implementierungen verfügbar

Argon2id: Vorteile und Nachteile

  • Vorteil: Gewinner der Password Hashing Competition, von OWASP 2026 klar empfohlen
  • Vorteil: Getrennt einstellbare Parameter für Speicher, Zeit und Parallelität
  • Vorteil: Kombiniert GPU-Resistenz mit Schutz gegen Seitenkanalangriffe
  • Nachteil: Benötigt in vielen Sprachen ein externes Zusatzpaket
  • Nachteil: Praktisch keine FIPS-140-validierten Module, ungeeignet für reine Compliance-Pflichtfälle
  • Nachteil: Höherer Speicherbedarf verlangt sorgfältige Kapazitätsplanung bei vielen gleichzeitigen Logins

Einsatzempfehlungen nach Anwendungsfall

Welcher Algorithmus passt, hängt stark vom konkreten Projekt ab. Die folgenden sechs Szenarien decken die häufigsten Entscheidungssituationen ab, mit denen Entwicklerteams 2026 konfrontiert sind.

  • Neue Webanwendung ohne Legacy-Zwänge: Argon2id mit den OWASP-Minimumwerten ist die naheliegende Wahl, weil kein Compliance-Druck besteht und moderne Serverinfrastruktur den Speicherbedarf problemlos trägt.
  • FIPS-140-regulierte Umgebung (Behörden, Finanzsektor): PBKDF2 bleibt hier oft die einzige praktikable Option, solange validierte Argon2id-Module fehlen.
  • Bestehendes System mit PBKDF2-Basis: Ein schrittweiser Übergang über erhöhte Iterationszahlen, gefolgt von einem Rehash auf Argon2id bei der nächsten Anmeldung, reduziert das Risiko eines harten Cutovers.
  • Shared Hosting mit wenig Arbeitsspeicher: scrypt mit reduzierten Parametern oder PBKDF2 mit hoher Iterationszahl sind pragmatische Kompromisse, wenn Argon2id-Parameter die Hosting-Grenzen sprengen würden.
  • Passwortmanager und Tresor-Software: Argon2id als Nutzeroption neben einem PBKDF2-Standard, wie bei Bitwarden umgesetzt, gibt sicherheitsbewussten Nutzern die Wahl, ohne die breite Kompatibilität zu verlieren.
  • Multi-Tenant-SaaS mit hoher gleichzeitiger Login-Last: Sorgfältige Kapazitätsplanung ist Pflicht, bevor Argon2id oder scrypt produktiv gehen, da sonst die Hashing-Last selbst zum Flaschenhals wird.

Migrationsleitfaden: Von PBKDF2 oder MD5 zu Argon2id wechseln

Ein Wechsel des Hashing-Algorithmus lässt sich fast nie auf einmal durchführen, weil gespeicherte Passwort-Hashes nicht entschlüsselt und neu berechnet werden können. Ein Hash ist bewusst eine Einwegfunktion, aus dem gespeicherten PBKDF2- oder bcrypt-Wert lässt sich das ursprüngliche Passwort nicht zurückrechnen, selbst mit Admin-Rechten auf der Datenbank. Der Standardweg führt deshalb über einen Rehash beim nächsten erfolgreichen Login, bei dem kurzzeitig das im Klartext eingegebene Passwort vorliegt und sofort mit dem neuen Zielverfahren neu gehasht werden kann. Die folgenden acht Schritte beschreiben den Ablauf, wie ihn unter anderem WordPress bei seinem Wechsel zu bcrypt und zahlreiche Django-Projekte beim Umstieg auf Argon2 praktiziert haben.

  1. Zielparameter festlegen: Speicherbedarf, Iterationen und Parallelität anhand der OWASP-Minimumwerte und der eigenen Serverkapazität bestimmen.
  2. Neue Hash-Bibliothek einbinden, etwa argon2-cffi in Python oder eine äquivalente Argon2id-Implementierung in der eigenen Sprachumgebung.
  3. Datenbankschema erweitern, sodass pro Nutzer gespeichert wird, mit welchem Algorithmus und welchen Parametern der aktuelle Hash erzeugt wurde.
  4. Verifikationslogik anpassen, damit bestehende PBKDF2- oder MD5-Hashes weiterhin korrekt geprüft werden können, während neue Hashes bereits Argon2id nutzen.
  5. Rehash-bei-Login einbauen: Nach erfolgreicher Anmeldung mit dem alten Verfahren wird das Passwort sofort mit Argon2id neu gehasht und gespeichert.
  6. Monitoring aufsetzen, um den Anteil der bereits migrierten Konten im Zeitverlauf zu beobachten und Lastspitzen durch die höheren Argon2id-Ressourcenanforderungen zu erkennen.
  7. Zeitfenster für inaktive Konten festlegen: Nutzer, die sich lange nicht einloggen, bleiben auf dem alten Hash, bis sie sich erneut anmelden oder ein erzwungener Passwort-Reset greift.
  8. Nach einer Übergangsfrist alte Hashing-Bibliotheken nur noch für die Verifikation, nicht mehr für die Erzeugung neuer Hashes vorhalten, bis der migrierte Anteil nahe 100 Prozent liegt.

Wichtig ist, während der gesamten Übergangszeit niemals ein Passwort zu verlangen, nur um den Algorithmus zu wechseln. Der Rehash passiert ausschließlich implizit beim nächsten normalen Login, was Nutzerfrust vermeidet und trotzdem zuverlässig zu einer vollständigen Migration führt, solange das Zeitfenster für inaktive Konten lang genug gewählt wird. Realistisch dauert eine vollständige Migration je nach Nutzeraktivität mehrere Monate bis über ein Jahr, bevor der Anteil der alten Hashes gegen null geht, weshalb Teams diesen Zeitraum von Anfang an fest einplanen sollten, statt ihn als kurzfristiges Übergangsprojekt zu behandeln.

Was Standardgremien und Entwickler zum Thema sagen

Die OWASP Cheat Sheet Series formuliert die Kernempfehlung unmissverständlich: “While Argon2id should be the best choice for password hashing, scrypt should be used when the former is not available.” Für Fälle mit Compliance-Zwang ergänzt die Organisation: “Since PBKDF2 is permitted by NIST SP 800-63B-4 and has FIPS-140 validated implementations, it should be the preferred algorithm when these are required.”

Auch außerhalb der Standarddokumente ist die Einschätzung der Entwicklerszene eindeutig. Die Softwareentwicklungs-Dozentin Stefania bringt es in einer Spring-Security-Erklärung so auf den Punkt: “Argon is the winner of a password hashing competition back in 2015.” Zur Einordnung von PBKDF2 fügt sie an: “PBKDF2 is the weakest, the fastest, and the oldest in the list. It’s recommended only for legacy systems.” Der Entwickler und Autor Rob Conery beschreibt in einem Vergleichsvideo zu Hashing-Verfahren, wie tief die alte bcrypt-Faustregel in der Branche verankert war: “If you’ve had to store sensitive user information in a database, you’ve probably heeded the advice to ‘just use bcrypt’.” Diese Aussage markiert gut, wie sich die Empfehlung seither weiterentwickelt hat, von “nutz einfach bcrypt” zu einer differenzierten Abwägung zwischen PBKDF2, scrypt und Argon2id je nach Einsatzszenario.

Das Urteil: Welcher Algorithmus gewinnt 2026

Für die große Mehrheit neuer Projekte ohne regulatorische Zwänge ist Argon2id 2026 die richtige Standardwahl. Die getrennt einstellbaren Parameter für Speicher, Zeit und Parallelität, die klare OWASP-Empfehlung und die wachsende Bibliotheksunterstützung sprechen für sich. Wer heute eine Anwendung ohne bestehende Passwort-Datenbank baut, sollte direkt mit Argon2id starten, anstatt später eine aufwendige Migration nachzuholen.

scrypt bleibt die sinnvolle zweite Wahl, wenn Argon2id auf der Zielplattform technisch nicht verfügbar ist, etwa in älteren Enterprise-Umgebungen oder bei stark eingeschränkten Paketquellen. Der Speicherbedarf von rund 128 MiB nach OWASP-Minimum ist höher als bei Argon2id, bietet aber immer noch deutlich mehr GPU-Resistenz als PBKDF2.

PBKDF2 verdient seinen Platz nicht mehr als Standard für neue, unregulierte Systeme, bleibt aber die richtige Wahl, wenn FIPS-140-Validierung zwingend vorgeschrieben ist oder wenn eine bestehende Codebasis aus guten Gründen noch nicht migriert werden kann. Entscheidend ist in jedem Fall, dass die gewählten Parameter regelmäßig überprüft und an aktuelle Hardware angepasst werden, wie der LastPass-Fall von 2022 eindrücklich zeigt. Ein Algorithmus allein schützt nicht, erst die Kombination aus modernem Verfahren, aktuellen Parametern und individuellem Salt pro Passwort ergibt den tatsächlichen Schutz vor Offline-Angriffen auf eine gestohlene Datenbank.

Die Beispiele von Django, Bitwarden, 1Password und WordPress zeigen zudem, dass selbst etablierte, stark genutzte Software nicht automatisch den theoretisch stärksten Algorithmus als Standard setzt. Kompatibilität, Bibliotheksreife und Compliance-Anforderungen spielen in der Praxis eine ebenso große Rolle wie die reine kryptografische Stärke. Für ein eigenes Projekt bedeutet das: Die richtige Entscheidung ergibt sich nicht aus einer einzelnen Tabelle, sondern aus dem Zusammenspiel von Bedrohungsmodell, Zielplattform, Compliance-Lage und verfügbarer Serverkapazität. Wer diese vier Faktoren für das eigene Projekt durchgeht, kommt 2026 fast immer zu einer klaren, gut begründbaren Entscheidung zwischen PBKDF2, scrypt und Argon2id.

Häufig gestellte Fragen

Ist Argon2id immer sicherer als scrypt und PBKDF2?

Bei korrekt gewählten, ausreichend hohen Parametern bietet Argon2id den besten Kompromiss aus Speicherhärte, Seitenkanalschutz und Flexibilität. Ein falsch konfiguriertes Argon2id mit zu niedrigem Speicherwert kann allerdings schwächer sein als ein sauber konfiguriertes scrypt oder ein PBKDF2 mit sehr hoher Iterationszahl. Die Parameterwahl entscheidet am Ende mehr als die reine Algorithmenwahl.

Warum nutzen Bitwarden und 1Password immer noch PBKDF2 als Standard?

Beide Anbieter dokumentieren PBKDF2-HMAC-SHA256 als Standardverfahren für die Ableitung des Master-Passwort-Schlüssels, Bitwarden mit 600.000 Iterationen. Der Grund liegt vor allem in breiter Client-Kompatibilität über viele Plattformen und Browser hinweg. Bitwarden bietet Argon2id zusätzlich als Option an, die Nutzer nach der Kontoerstellung manuell aktivieren können.

Muss ich meine komplette Nutzerdatenbank sofort migrieren, wenn ich auf Argon2id wechsle?

Nein. Der übliche Weg ist ein Rehash beim nächsten erfolgreichen Login, wie im Migrationsleitfaden oben beschrieben. Alte Hashes bleiben für die Verifikation gültig, bis der jeweilige Nutzer sich das nächste Mal anmeldet und dabei automatisch auf das neue Verfahren umgestellt wird.

Was bedeutet FIPS-140 und warum schränkt es die Algorithmenwahl ein?

FIPS-140 ist ein US-Standard für die Validierung kryptografischer Module, der häufig für Behörden, Finanzdienstleister und Zulieferer dieser Branchen vorgeschrieben ist. Da für PBKDF2 deutlich mehr validierte Implementierungen existieren als für scrypt oder Argon2id, bleibt PBKDF2 in diesen regulierten Umgebungen oft die einzige praktikable Wahl, selbst wenn Argon2id technisch stärker wäre. Für europäische und deutsche Unternehmen ohne direkten US-Behördenbezug greift diese Einschränkung in der Regel nicht, weshalb hier die reine Sicherheitsabwägung zwischen den drei Verfahren meist stärker ins Gewicht fällt als die Validierungsfrage.

Welche Rolle spielt der Salt bei allen drei Verfahren?

Ein individueller, zufälliger Salt pro Passwort ist bei PBKDF2, scrypt und Argon2id gleichermaßen Pflicht. Er verhindert, dass zwei Nutzer mit identischem Passwort denselben Hash erhalten, und macht vorberechnete Rainbow-Table-Angriffe wirkungslos. Ohne individuellen Salt verliert selbst das stärkste der drei Verfahren einen großen Teil seines Schutzeffekts, weil ein Angreifer dann nur einmal pro häufig genutztem Passwort rechnen muss, statt für jeden einzelnen Nutzer separat. Alle drei hier besprochenen Bibliotheken erzeugen den Salt standardmäßig automatisch und speichern ihn direkt zusammen mit dem Hash, sodass Entwicklerteams ihn in der Regel nicht manuell verwalten müssen.

Ist yescrypt bei Ubuntu eine vierte Alternative zu den drei Verfahren?

Für den Systemlogin unter Linux ja, für Webanwendungen spielt yescrypt bislang kaum eine Rolle. Ubuntu 22.04, 24.04, 25.04 und 25.10 nutzen yescrypt laut offizieller Ubuntu-Sicherheitsdokumentation für lokale Benutzerkonten in /etc/shadow. Für eigene Webanwendungen bleibt die Wahl zwischen PBKDF2, scrypt und Argon2id die relevante Entscheidung.

Wie hängt der LastPass-Vorfall von 2022 mit der Algorithmenwahl zusammen?

LastPass nutzte zum Zeitpunkt des Vorfalls 100.100 PBKDF2-Iterationen für die Ableitung des Master-Passwort-Schlüssels, wie das Unternehmen in seiner offiziellen Mitteilung vom 22. Dezember 2022 bestätigte. Der Fall zeigt vor allem, wie wichtig es ist, einmal gesetzte Parameter regelmäßig an aktuelle Hardware-Fähigkeiten anzupassen, unabhängig davon, welches der drei Verfahren eingesetzt wird.

Lohnt sich der Umstieg auf Argon2id für ein kleines Projekt mit wenigen hundert Nutzern?

Ja, gerade bei kleinen Projekten ist der Umstieg unkompliziert, weil die absolute Serverlast durch wenige hundert Nutzer gering bleibt und die OWASP-Minimumwerte von rund 19 MiB pro Login problemlos auf praktisch jeder modernen Serverumgebung laufen. Je früher im Projektlebenszyklus der Wechsel erfolgt, desto kleiner ist später der Migrationsaufwand.

Kann ich PBKDF2, scrypt und Argon2id in derselben Anwendung parallel einsetzen?

Ja, und das ist während einer Migration sogar der Normalfall. Solange für jeden gespeicherten Hash dokumentiert ist, mit welchem Algorithmus und welchen Parametern er erzeugt wurde, kann die Verifikationslogik beim Login automatisch das passende Verfahren auswählen. Django, WordPress und andere Frameworks setzen genau dieses Prinzip um, indem sie mehrere Hasher-Klassen gleichzeitig unterstützen und neue Passwörter stets mit dem jeweils aktuellen Standardverfahren erzeugen, während alte Hashes weiterhin korrekt geprüft werden.