Argon2id vs bcrypt vs scrypt: Vergleich 2026

Wer heute eine Login-Funktion baut, muss sich für ein Passwort-Hash-Verfahren entscheiden – und diese Entscheidung ist 2026 wichtiger als noch vor wenigen Jahren. Zwischen Argon2id, bcrypt und scrypt liegen teils riesige Unterschiede bei Rechenzeit, Speicherbedarf und Widerstandsfähigkeit gegen Cracking-Angriffe mit spezialisierter Hardware. Dieser Vergleich zeigt anhand aktueller Benchmarks aus drei unabhängigen Quellen, technischer Spezifikationen und realer Einsatzbeispiele, welches Verfahren für welchen Anwendungsfall taugt – und wo die jeweiligen Schwächen liegen.

Für Entwicklerteams in Österreich und im gesamten DACH-Raum ist die Frage keine akademische Übung. Wer personenbezogene Daten verarbeitet, muss sich an die DSGVO-Vorgaben zum Stand der Technik bei der Datensicherheit halten, und ein veraltetes Hash-Verfahren lässt sich im Ernstfall schwer als angemessene Schutzmaßnahme rechtfertigen. Der folgende Artikel liefert deshalb nicht nur Benchmark-Zahlen, sondern auch eine konkrete Spezifikationstabelle, einen Migrationsleitfaden und klare Einsatzempfehlungen für unterschiedliche Projektgrößen.

Warum Passwort-Hashing 2026 wichtiger ist denn je

Gestohlene Zugangsdatenbanken sind längst Alltag. Infostealer-Malware, Credential-Stuffing-Kampagnen und große Datenlecks sorgen dafür, dass Milliarden von Zugangsdaten im Umlauf sind. Ein Passwort-Hash-Verfahren entscheidet in diesem Szenario darüber, wie teuer es für Angreifer wird, aus einer gestohlenen Datenbank tatsächlich nutzbare Klartext-Passwörter zu gewinnen. Ein schwaches oder falsch konfiguriertes Verfahren macht aus einem Datenbank-Leak eine Passwort-Liste. Ein starkes, richtig parametrisiertes Verfahren macht aus demselben Leak Monate oder Jahre an Rechenaufwand pro Passwort.

Genau deshalb hat sich die Empfehlungslage in den letzten Jahren verschoben. Die OWASP Password Storage Cheat Sheet, die als De-facto-Standard für Entwickler gilt, führt Argon2id inzwischen klar als erste Wahl für neue Systeme. scrypt gilt als Alternative, wenn Argon2id aus technischen Gründen nicht verfügbar ist. bcrypt wird zunehmend als Kompatibilitätsoption für Altsysteme eingeordnet, nicht mehr als Standardempfehlung für neue Projekte. Wer heute noch unreflektiert bcrypt per Copy-paste aus einem zehn Jahre alten Tutorial übernimmt, baut womöglich ein schwächeres Sicherheitsniveau ein, als technisch notwendig wäre.

Gleichzeitig ist die Entscheidung keine reine Sicherheitsfrage. Jede zusätzliche Millisekunde Rechenzeit pro Login-Versuch multipliziert sich bei Diensten mit hohem Anmeldeaufkommen zu echten Serverkosten. Ein Verfahren, das offline-Angriffe massiv verteuert, aber online jeden Login spürbar verlangsamt, kann bei Lastspitzen zum Flaschenhals werden. Der folgende Vergleich arbeitet deshalb beide Seiten heraus: Sicherheitsgewinn und Betriebskosten.

Grundlagen: Was ein Passwort-Hash-Verfahren leisten muss

Ein Passwort-Hash ist keine Verschlüsselung, sondern eine Einwegfunktion. Aus dem Klartext-Passwort wird ein Wert berechnet, aus dem sich das Original praktisch nicht zurückrechnen lässt. Beim Login wird einfach erneut gehasht und verglichen. Drei Eigenschaften unterscheiden gute von schlechten Verfahren: ein individueller Salt pro Passwort, damit identische Passwörter nicht denselben Hash ergeben, ein einstellbarer Arbeitsfaktor, der die Berechnung künstlich verlangsamt, und im Idealfall ein hoher Speicherbedarf, der spezialisierte Angriffshardware ausbremst.

Diese drei Verfahren werden oft fälschlich mit allgemeinen Hashfunktionen wie SHA-256 verwechselt. Der entscheidende Unterschied: Eine klassische Hashfunktion ist auf Geschwindigkeit optimiert, weil sie etwa zur Integritätsprüfung von Dateien dient, wo schnelle Berechnung ein Vorteil ist. Ein Passwort-Hash-Verfahren will dagegen bewusst langsam und ressourcenintensiv sein, denn genau diese künstliche Verlangsamung macht massenhaftes Ausprobieren unwirtschaftlich. Wer SHA-256 ohne zusätzliche Verlangsamung direkt für Passwörter einsetzt, begeht einen der klassischsten Fehler in der angewandten Kryptografie, weil moderne Hardware Milliarden solcher Hashes pro Sekunde berechnen kann.

Genau an diesem dritten Punkt unterscheiden sich die drei Kandidaten grundlegend. bcrypt wurde 1999 von Niels Provos und David Mazières auf Basis der Blowfish-Chiffre entwickelt und ist rein CPU-hart: Es braucht kaum Arbeitsspeicher, dafür viele CPU-Zyklen. scrypt entstand 2009 durch Colin Percival für den Backup-Dienst Tarsnap und wurde bewusst als speicherhartes Verfahren konzipiert, um GPU- und ASIC-gestützte Angriffe zu verteuern. Argon2 gewann 2015 die Password Hashing Competition und kombiniert als Argon2id beide Ansätze: Es ist sowohl speicherhart als auch gegen Seitenkanalangriffe gehärtet.

Diese Reihenfolge der Entstehung ist kein Zufall. Jedes Verfahren ist eine Antwort auf die Schwächen seines Vorgängers – und genau das erklärt, warum die Empfehlungen 2026 so klar zugunsten von Argon2id ausfallen, während bcrypt eher aus Kompatibilitätsgründen überlebt.

Ein weiterer Faktor treibt diese Entwicklung zusätzlich: Grafikkarten und spezialisierte Mining-Hardware sind seit den 1990er-Jahren um Größenordnungen leistungsfähiger und gleichzeitig günstiger geworden. Ein Verfahren, das rein auf CPU-Zyklen setzt, verliert dadurch über die Jahre relativ an Schutzwirkung, selbst wenn der Cost-Faktor regelmäßig angehoben wird, weil GPUs CPU-lastige Operationen massiv parallelisieren können. Speicherhärte wirkt diesem Trend entgegen, weil Speicherbausteine nicht im gleichen Tempo billiger und schneller werden wie reine Rechenkerne. Das ist der eigentliche strategische Grund, warum sich die Branche von rein CPU-harten Verfahren wegbewegt.

Argon2id, bcrypt und scrypt im Kurzporträt

Argon2id: der aktuelle OWASP-Standard

Argon2 existiert in drei Varianten: Argon2d (optimiert gegen GPU-Cracking, aber anfällig für Seitenkanalangriffe), Argon2i (resistent gegen Seitenkanäle, aber langsamer gegen GPU-Angriffe) und Argon2id als Hybrid aus beiden. Für Passwort-Hashing empfiehlt OWASP ausschließlich Argon2id, da es die Stärken beider Varianten vereint. Als Ausgangsparameter nennt OWASP mindestens 19 MiB Speicher, 2 Iterationen und einen Parallelitätsgrad von 1. Alternativ wird eine Konfiguration mit etwa 46 MiB Speicher, 1 Iteration und Parallelitätsgrad 1 genannt. Beide Werte sind explizit als Startpunkt gedacht, nicht als fixe Vorgabe – Teams sollen auf der eigenen Server-Flotte messen und die Parameter an die tatsächliche Hardware anpassen.

Technisch gesehen arbeitet Argon2id intern mit einer Speichermatrix, die während der Hash-Berechnung mehrfach durchlaufen wird. Jeder Durchlauf greift auf vorherige Speicherblöcke zu, wobei die genaue Zugriffsreihenfolge bei der id-Variante zur Hälfte datenabhängig und zur Hälfte datenunabhängig gestaltet ist. Dadurch lässt sich der Speicherbedarf nicht durch geschickte Zeit-Speicher-Tradeoffs umgehen, wie es bei einfacheren Verfahren teils möglich ist. Für Implementierungen empfiehlt sich die Referenzbibliothek libsodium oder sprachspezifische Wrapper wie argon2-cffi für Python, da selbst geschriebene Implementierungen von Speicherhärte-Algorithmen erfahrungsgemäß fehleranfällig sind.

bcrypt: der Klassiker mit Altlasten

bcrypt ist über 25 Jahre alt und entsprechend tief in Standardbibliotheken verwurzelt, etwa in PHP über die Funktion password_hash() oder in vielen Node.js- und Java-Frameworks. OWASP empfiehlt einen Arbeitsfaktor (Cost-Faktor) von mindestens 10, auf moderner Hardware idealerweise 12 oder höher. Der große praktische Haken: bcrypt verarbeitet nur die ersten 72 Byte eines Passworts. Längere Passphrasen werden faktisch abgeschnitten, was Entwicklerinnen und Entwickler explizit behandeln müssen, statt das Passwort einfach stillschweigend zu kürzen. Weil bcrypt nur wenige Kilobyte Arbeitsspeicher benötigt, lässt es sich auf spezialisierter Cracking-Hardware vergleichsweise günstig parallelisieren.

Der Cost-Faktor bei bcrypt wirkt exponentiell: Jede Erhöhung um 1 verdoppelt die Rechenzeit. Der Sprung von Cost 10 auf Cost 12 bedeutet also grob die vierfache Rechenzeit pro Hash, was sich in den weiter unten gezeigten Benchmark-Zahlen deutlich widerspiegelt. Dieser exponentielle Zusammenhang macht bcrypt theoretisch beliebig skalierbar in der Sicherheit, stößt aber praktisch an eine Grenze, weil die Login-Latenz für echte Nutzer irgendwann spürbar unangenehm wird. Ein weiterer, oft übersehener Punkt: Manche ältere bcrypt-Implementierungen behandeln Zeichen jenseits von Byte 72 unterschiedlich, was bei einem Bibliothekswechsel zu inkompatiblen Hashes führen kann, wenn man nicht vorab testet.

scrypt: speicherhart, aber selten erste Wahl

scrypt war das erste verbreitete Verfahren, das Speicherhärte systematisch als Designziel verfolgte. OWASP nennt als Minimum N = 2^17 (entspricht 131.072), r = 8 und p = 1, was in etwa 128 MiB Speicherbedarf pro Hash-Berechnung resultiert. Das macht scrypt zu einer legitimen Alternative, wenn Argon2id in einer Programmiersprache oder Umgebung nicht verfügbar ist. Bekannt ist scrypt zudem aus dem Kryptowährungs-Umfeld, wo es als Proof-of-Work-Funktion etwa bei Litecoin zum Einsatz kam, sowie als Schlüsselableitungsfunktion in älteren Wallet-Formaten. Für reines Passwort-Hashing in Webanwendungen gilt scrypt heute aber meist als zweite Wahl hinter Argon2id.

Die drei scrypt-Parameter steuern unterschiedliche Ressourcen: N bestimmt die Speichermenge und die Anzahl sequenzieller Rechenschritte, r beeinflusst die Blockgröße pro Mischoperation, und p erlaubt eine parallele Verarbeitung mehrerer unabhängiger Ketten. Weil N direkt exponentiell in den Speicherbedarf eingeht, lässt sich scrypt grob skalieren, allerdings mit dem Nachteil, dass bereits kleine Erhöhungen von N den RAM-Bedarf schnell in Bereiche treiben, die auf kleineren Servern oder in Containern mit engen Speicherlimits ein eigenes Betriebsrisiko darstellen.

Technische Spezifikationen im direkten Vergleich

Die folgende Tabelle fasst die wichtigsten technischen Eckdaten aller drei Verfahren zusammen, basierend auf den aktuellen OWASP-Empfehlungen und den zugrunde liegenden Spezifikationen.

Merkmal	Argon2id	bcrypt	scrypt
Erstveröffentlichung	2015	1999	2009
Entwickler	Alex Biryukov, Daniel Dinu, Dmitry Khovratovich	Niels Provos, David Mazières	Colin Percival
Herkunft / Anlass	Gewinner der Password Hashing Competition	Basiert auf der Blowfish-Chiffre	Entwickelt für den Backup-Dienst Tarsnap
Härtungstyp	Speicher- und rechenhart (Hybrid)	Rechenhart (CPU)	Speicherhart
OWASP-Einstufung 2026	Erste Wahl für neue Systeme	Fallback für Altsysteme	Alternative, wenn Argon2id fehlt
OWASP-Minimalparameter	19 MiB Speicher, 2 Iterationen, Parallelität 1	Cost-Faktor ≥ 10	N = 2^17, r = 8, p = 1
Typischer Speicherbedarf pro Hash	19–64 MiB (konfigurierbar)	ca. 4 KiB	ca. 128 MiB (OWASP-Minimum)
Passwort-Längenlimit	Keine praktische Begrenzung	72 Byte (harte Grenze)	Keine praktische Begrenzung
Parallelisierbarkeit (Verfahren selbst)	Konfigurierbar über Parallelitätsgrad	Nicht parallelisierbar innerhalb eines Hashs	Konfigurierbar über Parameter p
GPU/ASIC-Resistenz	Hoch (durch Speicherhärte)	Gering bis mittel	Hoch (durch Speicherhärte)
Seitenkanal-Resistenz	Hoch (Hybrid-Design)	Mittel	Mittel
Standardisierung	RFC 9106 (IETF)	Kein formelles IETF-RFC, aber breiter De-facto-Standard	RFC 7914 (IETF)
Typische Bibliotheken	libsodium, argon2-cffi, Spring Security	bcrypt-Pakete in PHP, Node.js, Java, Ruby	OpenSSL, Node.js crypto-Modul, Python hashlib

Auffällig ist der Speicherbedarf: bcrypt begnügt sich mit wenigen Kilobyte, während scrypt und Argon2id gezielt zweistellige bis dreistellige Megabyte-Werte verlangen. Genau dieser Unterschied ist der Kern der Sicherheitsdebatte, weil Speicherhärte Angriffe auf spezialisierter Hardware massiv verteuert.

Bemerkenswert ist zudem der Stand der formellen Standardisierung: Argon2 ist seit 2021 als RFC 9106 bei der Internet Engineering Task Force verankert, scrypt bereits seit 2016 als RFC 7914. bcrypt hat dagegen nie den Weg durch einen formellen IETF-Standardisierungsprozess genommen, sondern blieb ein De-facto-Standard, der sich allein durch breite Verbreitung in Bibliotheken und Frameworks etabliert hat. Für sicherheitskritische Projekte, die eine Begründung auf Basis anerkannter Standards benötigen, kann dieser formale Unterschied bei der Auswahl zusätzlich den Ausschlag geben.

Benchmark-Ergebnisse aus drei unabhängigen Quellen

Rohe Rechenzeiten sagen nur etwas aus, wenn man Hardware und Parameter kennt. Deshalb lohnt sich der Blick auf mehrere unabhängig gemessene Benchmarks statt auf eine einzelne Zahl. Ein 2026 veröffentlichter Benchmark von Viktar Patotski misst Argon2id mit den OWASP-Minimalparametern (19 MiB, 2 Iterationen, Parallelität 1) bei rund 19,5 Millisekunden pro Hash, bcrypt mit Cost-Faktor 10 bei rund 47,0 Millisekunden und scrypt mit der speicherharten OWASP-Konfiguration bei rund 265,1 Millisekunden.

Ein zweiter, unabhängiger Vergleich von PkgPulse kommt zu abweichenden, aber ähnlich gelagerten Werten: bcrypt mit Cost 10 liegt dort bei etwa 65 Millisekunden, mit Cost 12 bei rund 250 Millisekunden. Argon2id wird mit rund 55 Millisekunden bei 19 MiB und 2 Iterationen sowie mit rund 180 Millisekunden bei einer stärkeren Konfiguration von 64 MiB und 3 Iterationen angegeben. Ein dritter Benchmark von MojoAuth, gemessen auf einer AWS-c7i.xlarge-Instanz unter Ubuntu 24.04, ermittelt für bcrypt mit Cost 11 rund 125 Millisekunden und mit Cost 12 rund 249 Millisekunden pro Hash.

Quelle	Hardware/Setup	Argon2id	bcrypt	scrypt
Patotski (2026)	Nicht spezifizierte Testumgebung, OWASP-Minimalparameter	~19,5 ms	~47,0 ms (Cost 10)	~265,1 ms (128 MiB)
PkgPulse (2026)	Standard-Benchmark-Setup, zwei Parametersätze	~55 ms / ~180 ms	~65 ms (Cost 10) / ~250 ms (Cost 12)	Nicht separat ausgewiesen
MojoAuth (2026)	AWS c7i.xlarge, Ubuntu 24.04	Nicht separat ausgewiesen	~125 ms (Cost 11) / ~249 ms (Cost 12)	Nicht separat ausgewiesen

Die absoluten Zahlen schwanken je nach Prozessor, Bibliotheksimplementierung und gewählten Parametern erheblich – das ist erwartbar und kein Widerspruch zwischen den Quellen. Der Trend ist in allen drei Messungen aber derselbe: Argon2id liegt bei vergleichbaren Sicherheitsniveaus meist im unteren bis mittleren zweistelligen Millisekundenbereich, bcrypt bewegt sich bei empfohlenen Cost-Faktoren im mittleren zweistelligen bis niedrigen dreistelligen Bereich, und scrypt landet mit seiner hohen Speicheranforderung am oberen Ende. Für die Praxis heißt das: Rohbenchmarks aus Blogposts sind Richtwerte, keine Garantien. Jedes Team sollte die Parameter final auf der eigenen Produktionshardware messen.

Salt, Pepper und zusätzliche Schutzschichten

Alle drei Verfahren erzeugen pro Passwort automatisch einen zufälligen Salt, der zusammen mit dem Hash gespeichert wird. Der Salt sorgt dafür, dass zwei Nutzer mit identischem Passwort unterschiedliche Hash-Werte erhalten, und verhindert so den Einsatz vorab berechneter Rainbow Tables. Ohne Salt könnten Angreifer eine einmal erstellte Tabelle häufiger Passwörter gegen beliebig viele gestohlene Datenbanken wiederverwenden. Mit individuellem Salt muss jedes Passwort einzeln angegriffen werden, was den Aufwand für Angreifer linear mit der Anzahl der Nutzerkonten erhöht.

Ein zusätzlicher, optionaler Schutzmechanismus ist der sogenannte Pepper: ein zweiter, geheimer Wert, der serverseitig getrennt von der Datenbank gespeichert wird, etwa in einem Secrets-Manager oder Hardware-Sicherheitsmodul. Während der Salt öffentlich mit dem Hash gespeichert werden darf, bleibt der Pepper geheim und wird bei jeder Hash-Berechnung zusätzlich eingerechnet. Gelingt einem Angreifer der Diebstahl der Passwort-Datenbank, aber nicht des separat gespeicherten Pepper, bleibt ein Offline-Angriff deutlich erschwert, weil der fehlende Pepper-Wert zusätzlich erraten werden müsste. In der Praxis lohnt sich ein Pepper vor allem für Dienste mit besonders hohem Schutzbedarf, da er zusätzliche Betriebskomplexität bei Schlüsselrotation und Secrets-Management mit sich bringt.

Sicherheit im Vergleich: GPU-Resistenz und Seitenkanäle

Die reine Rechenzeit ist nur die halbe Geschichte. Entscheidend für die Sicherheit gegen Offline-Angriffe ist, wie teuer sich ein Verfahren auf spezialisierter Hardware parallelisieren lässt. Weil bcrypt nur wenige Kilobyte Speicher benötigt, lassen sich auf einer einzelnen GPU gleichzeitig tausende Hash-Versuche parallel rechnen. Eine Analyse von QuantumSecurity schätzt die Cracking-Rate für bcrypt mit Cost-Faktor 12 auf rund 10 Gigabyte pro Sekunde und Dollar GPU-Leistung – ein Wert, der die praktische Angreifbarkeit in Relation zu Hardwarekosten setzt.

scrypt und Argon2id drehen dieses Verhältnis um: Weil jeder einzelne Hash-Versuch 64 bis 128 MiB Arbeitsspeicher belegt, kann eine GPU mit begrenztem Speicher nur eine viel kleinere Anzahl paralleler Versuche gleichzeitig ausführen. Jeder zusätzliche parallele Angriffsversuch kostet damit nicht nur mehr Rechenzeit, sondern auch zusätzlichen, teuren Speicher – ein Kostenfaktor, der bei bcrypt praktisch wegfällt. Das ist der Kern, warum OWASP speicherharte Verfahren bevorzugt.

Seitenkanalangriffe sind ein zweiter, oft unterschätzter Aspekt. Argon2d ist zwar besonders GPU-resistent, aber anfällig für Timing- oder Cache-basierte Seitenkanalangriffe, weil der Speicherzugriffsmuster vom Passwort selbst abhängt. Argon2i vermeidet dieses Problem, verliert dafür etwas GPU-Resistenz. Argon2id als Hybrid wurde genau deshalb entwickelt und gilt heute als der Kompromiss mit der höchsten Gesamtsicherheit. Unabhängig vom gewählten Algorithmus gilt zudem eine Grundregel: Der Vergleich von Hash-Werten beim Login muss immer über eine konstante-Zeit-Vergleichsfunktion erfolgen, damit nicht schon die Antwortzeit des Servers Rückschlüsse auf die Korrektheit einzelner Zeichen zulässt.

Wichtig ist außerdem, zwischen zwei grundsätzlich verschiedenen Angriffsszenarien zu unterscheiden. Beim Credential Stuffing testen Angreifer bereits bekannte, aus anderen Diensten gestohlene Kombinationen aus Benutzername und Passwort direkt gegen die Login-API eines Dienstes. Hier hilft das beste Hash-Verfahren wenig, weil der Angreifer das Passwort bereits kennt und keinen Hash knacken muss. Beim Offline-Cracking dagegen besitzt der Angreifer die gestohlene Hash-Datenbank und versucht, möglichst viele Hashes in möglichst kurzer Zeit zurückzurechnen. Genau für dieses zweite Szenario sind Argon2id, bcrypt und scrypt die relevante Verteidigungslinie, während Credential Stuffing eigene Gegenmaßnahmen wie Passwort-Wiederverwendungsprüfungen und Multi-Faktor-Authentifizierung braucht.

Infrastrukturkosten und Server-Kapazität

Sicherheit kostet Rechenzeit, und Rechenzeit kostet Server-Kapazität. Dieser Zusammenhang wird bei der Auswahl eines Passwort-Hash-Verfahrens häufig unterschätzt, ist aber für jeden Dienst mit nennenswertem Anmeldeaufkommen betriebswirtschaftlich relevant. Die folgende Tabelle ordnet die gemessenen Zeiten aus dem vorherigen Abschnitt in eine grobe Kapazitätsrechnung ein.

Verfahren (typische Einstellung)	Zeit pro Hash (Richtwert)	Geschätzte Logins/Sek. je CPU-Kern	Implikation für Kapazitätsplanung
bcrypt, Cost 10	~47–65 ms	~15–21	Niedrige Serverlast, aber geringerer Offline-Schutz
bcrypt, Cost 12	~249–250 ms	~4	Höhere Serverlast bei Login-Spitzen möglich
Argon2id, OWASP-Minimum (19 MiB)	~19,5–55 ms	~18–51	Guter Kompromiss aus Last und Sicherheit
Argon2id, verstärkt (64 MiB)	~180 ms	~6	Nur bei ausreichender Kernzahl sinnvoll
scrypt, OWASP-Minimum (128 MiB)	~265 ms	~4	Zusätzlich hoher RAM-Bedarf pro gleichzeitigem Login

Eine Analyse von MojoAuth zu CPU-Engpässen bei Passwort-Hashing unter hoher Last illustriert das Problem konkret: Schon 10.000 Logins pro Sekunde können auf einer typischen 8-vCPU-Maschine jeden Kern auslasten, wenn bcrypt mit Cost-Faktor 12 im Einsatz ist und jede Verifikation rund 250 Millisekunden reine CPU-Zeit benötigt. Bei Diensten mit planbaren Lastspitzen – etwa zu Stoßzeiten nach Werbekampagnen oder bei Ticketverkäufen – kann ein zu hoch gewähltes Sicherheitsniveau den Login-Server in die Knie zwingen, bevor überhaupt ein Angreifer aktiv wird. Die praktische Konsequenz: Serverkapazität und Sicherheitsniveau müssen gemeinsam dimensioniert werden, nicht isoliert.

Für Teams, die Kapazitäten planen, empfiehlt sich ein zweistufiges Vorgehen: Zunächst wird mit Lasttests unter realistischen Bedingungen ermittelt, wie viele gleichzeitige Logins die vorhandene Infrastruktur mit den gewählten Hash-Parametern verkraftet. Anschließend lässt sich daraus eine horizontale Skalierungsstrategie ableiten, etwa durch Auto-Scaling-Gruppen, die bei steigender Login-Last automatisch zusätzliche Instanzen starten. Wichtig dabei: Die Hash-Berechnung sollte nie im selben Thread-Pool laufen wie zeitkritische Anfragen, damit ein kurzfristiger Login-Ansturm nicht die gesamte Anwendung ausbremst, sondern isoliert bleibt.

Serverless und Edge: Wenn Ressourcen knapp sind

Eine zusätzliche Komplikation entsteht in Serverless- und Edge-Umgebungen wie AWS Lambda oder Cloudflare Workers. Diese Plattformen begrenzen typischerweise sowohl Arbeitsspeicher als auch Ausführungszeit pro Funktionsaufruf strikt, und beides kostet zusätzlich Geld pro Megabyte und Millisekunde. scrypts OWASP-Minimum von rund 128 MiB kann in speicherbeschränkten Funktionsinstanzen bereits einen erheblichen Anteil des verfügbaren Budgets aufbrauchen, besonders wenn mehrere Logins parallel verarbeitet werden müssen.

Argon2id lässt sich in solchen Umgebungen über die Parameter feiner abstufen: Ein reduzierter Speicherwert von etwa 19 bis 32 MiB bei entsprechend mehr Iterationen kann einen ähnlichen Sicherheitsgewinn liefern wie ein höherer Speicherwert bei weniger Iterationen, ohne das Speicherbudget der Funktion zu sprengen. bcrypt bleibt wegen seines minimalen Speicherbedarfs in extrem ressourcenbeschränkten Umgebungen weiterhin eine pragmatische Option, allerdings nur, wenn man das geringere Sicherheitsniveau gegenüber Offline-Angriffen bewusst in Kauf nimmt. Wer auf Serverless setzt, sollte die gewählten Parameter also nicht nur gegen Sicherheitsvorgaben, sondern auch gegen das tatsächliche Preismodell der Plattform testen.

Ein praktischer Nebeneffekt des Serverless-Preismodells: Da viele Anbieter nach zugewiesenem Speicher und tatsächlicher Ausführungszeit abrechnen, lässt sich der Kostenunterschied zwischen den drei Verfahren direkt in Euro beziffern. Eine Funktion, die mit 128 MiB zusätzlichem Speicherbudget für scrypt konfiguriert werden muss, verursacht bei gleicher Aufrufzahl spürbar höhere laufende Kosten als eine Funktion, die mit reduziertem Argon2id-Speicher auskommt. Für Teams mit engem Infrastrukturbudget ist das ein zusätzliches, rein wirtschaftliches Argument für eine sorgfältige Parameterwahl, unabhängig vom reinen Sicherheitsaspekt.

Praxisbeispiele aus dem Alltag

Die drei Verfahren tauchen in sehr unterschiedlichen realen Kontexten auf, was die jeweilige Stärke gut illustriert. Die folgenden sechs Beispiele zeigen, wie unterschiedlich die Anforderungen an Rechenzeit, Speicherbudget und Kompatibilität je nach Einsatzbereich ausfallen können.

Passwort-Manager: Moderne Passwort-Tresore wie KeePassXC setzen im KDBX4-Dateiformat auf Argon2 zur Ableitung des Verschlüsselungsschlüssels aus dem Master-Passwort, weil hier maximale Offline-Resistenz wichtiger ist als minimale Rechenzeit. Ein Tresor wird typischerweise nur wenige Male täglich entsperrt, sodass selbst mehrere hundert Millisekunden Wartezeit kaum auffallen, während ein gestohlener Tresor dem Angreifer maximalen Widerstand entgegensetzen soll.
Legacy-Webanwendungen: Viele PHP-Anwendungen, die seit Jahren im Betrieb sind, nutzen weiterhin die eingebaute bcrypt-Funktion password_hash(), weil ein Wechsel der Hash-Datenbank ohne Breaking Change aufwendig ist. Hier empfiehlt sich meist zunächst eine Erhöhung des Cost-Faktors, bevor eine vollständige Migration angegangen wird.
Kryptowährungs-Wallets: Ältere Wallet-Keystore-Formate, etwa im Ethereum-Umfeld, verwenden traditionell scrypt zur Ableitung des Verschlüsselungsschlüssels aus einer Passphrase, bevor private Schlüssel entschlüsselt werden. Die Wahl von scrypt in diesem Umfeld ist historisch gewachsen und wird aus Kompatibilitätsgründen beibehalten, auch wenn neuere Wallet-Implementierungen zunehmend auf Argon2id umsteigen.
Hochfrequentierte Login-APIs: SaaS-Anbieter mit planbaren Lastspitzen, etwa bei Kampagnenstarts oder Produktlaunches, tunen Argon2id gezielt auf niedrigere Speicherwerte, um Login-Stürme ohne Serverüberlastung abzufedern, ohne dabei vollständig auf Speicherhärte zu verzichten.
Serverless-Backends: Teams, die Authentifizierung über Edge-Funktionen abwickeln, wählen häufig reduzierte Argon2id-Parameter oder in Ausnahmefällen bcrypt, um innerhalb enger Speicher- und Zeitbudgets der jeweiligen Plattform zu bleiben, ohne das Abrechnungsmodell des Anbieters zu sprengen.
Behörden- und Finanzanwendungen: In regulierten Branchen mit langen Freigabezyklen ist bcrypt wegen seiner langen Historie und breiten Zertifizierungsbasis teilweise noch die anerkannte Vorgabe, während eine Migration zu Argon2id parallel vorbereitet wird, oft begleitet von internen Sicherheitsaudits.
Interne Admin-Panels mit kleiner Nutzerzahl: Bei internen Tools mit wenigen Dutzend Accounts spielt die Serverlast praktisch keine Rolle, weshalb sich hier besonders hohe Argon2id-Parameter jenseits der OWASP-Minimalwerte anbieten, ohne dass spürbare Betriebskosten entstehen.

Häufige Implementierungsfehler beim Passwort-Hashing

Unabhängig vom gewählten Algorithmus tauchen in Code-Reviews immer wieder dieselben Fehler auf. Ein verbreiteter Fehler ist das stillschweigende Abschneiden zu langer Passwörter bei bcrypt, ohne die Nutzer darüber zu informieren oder das Passwort vorher sinnvoll zu vorhashen. Dadurch glauben Nutzer, ein langes, sicheres Passwort gewählt zu haben, während tatsächlich nur die ersten 72 Byte in die Sicherheit einfließen.

Ein zweiter häufiger Fehler ist die Wiederverwendung eines einzigen, hartkodierten Salt-Werts für alle Nutzer, oft aus Unwissenheit über die eingebauten Funktionen der verwendeten Bibliothek. Moderne Implementierungen von Argon2id, bcrypt und scrypt generieren den Salt automatisch pro Aufruf; wer diesen Mechanismus manuell überschreibt, hebelt einen zentralen Schutzmechanismus aus. Ebenso riskant ist es, Parameter wie Speicherbedarf oder Iterationszahl einmal zu Projektbeginn festzulegen und nie wieder zu überprüfen. Hardware wird schneller, und ein Parametersatz, der 2022 angemessen war, kann 2026 bereits zu schwach sein.

Schließlich unterschätzen viele Teams die Bedeutung eines Fehlerbudgets bei fehlgeschlagenen Login-Versuchen. Selbst das stärkste Hash-Verfahren schützt nicht vor Online-Angriffen, bei denen ein Angreifer direkt gegen die Login-API testet, statt eine gestohlene Datenbank offline anzugreifen. Rate-Limiting, Account-Lockouts nach mehreren Fehlversuchen und die Überwachung ungewöhnlicher Login-Muster bleiben deshalb notwendige Ergänzungen zu jedem der drei hier verglichenen Verfahren, nicht ein Ersatz dafür.

Migrationsleitfaden: Von bcrypt zu Argon2id wechseln

Eine bestehende bcrypt-Datenbank lässt sich nicht einfach auf Argon2id umrechnen, weil Hash-Verfahren bewusst nicht umkehrbar sind. Die gängige Praxis ist deshalb eine schrittweise Migration, die bei jedem erfolgreichen Login automatisch neu hasht.

Bestandsaufnahme machen: Wie viele aktive Nutzerkonten gibt es, wie hoch ist die durchschnittliche Login-Frequenz, und welche bcrypt-Bibliothek sowie welcher Cost-Faktor sind aktuell im Einsatz?
Argon2id-Bibliothek für die eingesetzte Programmiersprache auswählen und in einer Staging-Umgebung testen (etwa libsodium oder argon2-cffi).
Startparameter nach OWASP-Empfehlung setzen (19 MiB, 2 Iterationen, Parallelität 1) und auf repräsentativer Produktionshardware die tatsächliche Latenz messen.
Datenbankschema um ein Feld erweitern, das den verwendeten Hash-Algorithmus pro Nutzer-Datensatz speichert, damit alte bcrypt-Hashes und neue Argon2id-Hashes parallel existieren können.
Beim nächsten erfolgreichen Login eines Nutzers das Passwort gegen den gespeicherten bcrypt-Hash prüfen, bei Erfolg sofort einen neuen Argon2id-Hash berechnen und den alten Eintrag ersetzen.
Für Nutzer, die sich lange nicht einloggen, optional eine Erinnerung zur Passwort-Aktualisierung einplanen, um die Migration nach einigen Monaten abzuschließen.
Monitoring für Login-Latenz und CPU-Auslastung einrichten, da während der Übergangsphase zwei unterschiedlich teure Verfahren gleichzeitig laufen.
Nach vollständiger Migration den bcrypt-Verifikationscode im Login-Pfad entfernen, um die Angriffsfläche zu reduzieren und Wartungsaufwand zu senken.

Dieser Ansatz, oft als “Rehash-on-Login” bezeichnet, vermeidet ein riskantes Big-Bang-Update und verteilt die Rechenlast der Migration über die normale Nutzungsfrequenz. Nachteil: Nutzer, die sich sehr selten einloggen, bleiben entsprechend länger auf dem alten Verfahren – ein Punkt, der in der Kommunikation an Sicherheitsverantwortliche offen benannt werden sollte.

Für Dienste mit besonders sensiblen Nutzerdaten lohnt sich zusätzlich eine erzwungene Migration: Nach einer angekündigten Übergangsfrist, etwa sechs bis zwölf Monate, werden verbliebene bcrypt-Hashes invalidiert und betroffene Nutzer beim nächsten Besuch zu einem Passwort-Reset aufgefordert. Das ist unbequemer für Einzelne, schließt aber zuverlässig die Lücke, die reines Rehash-on-Login offenlässt. Welcher Weg sich eignet, hängt vom Risikoprofil der Anwendung ab und sollte gemeinsam mit den jeweils Verantwortlichen für Informationssicherheit festgelegt werden, nicht allein von der Entwicklungsabteilung.

Vor- und Nachteile im Überblick

Argon2id

Vorteil: Aktuell höchste OWASP-Empfehlung, hybride Resistenz gegen GPU- und Seitenkanalangriffe
Vorteil: Parameter fein abstufbar zwischen Speicher, Iterationen und Parallelität
Nachteil: Jüngstes Verfahren der drei, dadurch in manchen älteren Umgebungen noch nicht verfügbar
Nachteil: Höherer Speicherbedarf kann in stark ressourcenbeschränkten Umgebungen zum Problem werden

bcrypt

Vorteil: Extrem weit verbreitet, in praktisch jeder Sprache und jedem Framework verfügbar
Vorteil: Minimaler Speicherbedarf, dadurch auch auf sehr kleinen Systemen praktikabel
Nachteil: 72-Byte-Passwortlimit erfordert explizite Behandlung im Code
Nachteil: Geringere GPU-Resistenz, dadurch relativ günstiger auf Spezialhardware zu knacken

scrypt

Vorteil: Hohe Speicherhärte, etablierter IETF-Standard (RFC 7914)
Vorteil: Bewährt im Einsatz bei Schlüsselableitung, unter anderem im Kryptowährungs-Umfeld
Nachteil: Höchste gemessene Latenz der drei Verfahren bei OWASP-Minimalparametern
Nachteil: Seltener als erste Empfehlung genannt, dadurch weniger aktuelle Tooling-Unterstützung als Argon2id

In der Summe zeigt sich ein klares Bild: Argon2id vereint die meisten Vorteile auf sich, verlangt dafür aber die sorgfältigste Parametrisierung. bcrypt punktet bei Einfachheit und Kompatibilität, scrypt bei etablierter Speicherhärte in bestehenden Systemen. Keines der drei Verfahren ist in jedem Szenario die objektiv richtige Wahl – die Entscheidung hängt immer vom konkreten Kontext ab, den die folgenden Einsatzempfehlungen aufschlüsseln.

Einsatzempfehlungen nach Anwendungsfall

Welches Verfahren sich am besten eignet, hängt stark vom konkreten Szenario ab, von der erwarteten Nutzerzahl über die verfügbare Serverhardware bis zu regulatorischen Vorgaben der jeweiligen Branche. Die folgenden sechs Empfehlungen fassen die wichtigsten Fälle zusammen und lassen sich meist direkt auf vergleichbare Projekte übertragen.

Neue Web- oder Mobile-Anwendung ohne Altlasten: Argon2id mit den OWASP-Startparametern einsetzen und auf Produktionshardware feinjustieren.
Login-API mit sehr hohem, planbarem Anmeldeaufkommen: Argon2id mit reduziertem Speicherwert wählen, um Latenz und Serverlast im Griff zu behalten, statt pauschal die Sicherheit zu maximieren.
Bestehendes System mit großer bcrypt-Nutzerdatenbank: bcrypt-Cost-Faktor zunächst auf mindestens 12 anheben, parallel eine Rehash-on-Login-Migration zu Argon2id vorbereiten.
Serverless- oder Edge-Deployment mit engem Speicherbudget: Argon2id mit stark reduziertem Speicherparameter testen, scrypt wegen seines hohen RAM-Bedarfs eher vermeiden.
Schlüsselableitung aus einer Passphrase für Verschlüsselung (nicht reines Login-Passwort): Argon2id als moderne Wahl, scrypt als etablierte Alternative bei bestehender Kompatibilitätsanforderung.
Regulierte Branche mit langen Freigabeprozessen für neue Kryptoverfahren: bcrypt mit hohem Cost-Faktor als Übergangslösung beibehalten, Migrationsplan zu Argon2id aber aktiv budgetieren statt auf unbestimmte Zeit verschieben.

Unabhängig von der konkreten Empfehlung gilt: Die Wahl des Algorithmus ist nur der erste Schritt. Mindestens ebenso wichtig ist, die gewählten Parameter regelmäßig zu überprüfen und an aktuelle Hardware-Entwicklungen anzupassen, statt eine einmal getroffene Entscheidung über Jahre unverändert zu lassen.

Post-Quanten-Perspektive: Bleibt Passwort-Hashing sicher?

Mit der Standardisierung von ML-KEM (FIPS 203), ML-DSA (FIPS 204) und SLH-DSA (FIPS 205) durch das NIST im August 2024 ist die Debatte um quantenresistente Kryptografie in der Praxis angekommen. Für Entwicklerinnen und Entwickler, die sich um Passwort-Hashing kümmern, ist die gute Nachricht: Argon2id, bcrypt und scrypt sind von dieser Umstellung nicht direkt betroffen. Shors Algorithmus, der asymmetrische Verfahren wie RSA oder elliptische Kurven bedroht, bricht keine symmetrischen Hash- oder KDF-Konstruktionen. Ein gut parametrisiertes Argon2id bleibt auch mit einem leistungsfähigen Quantencomputer eine Einwegfunktion.

Relevanter ist die post-quantenkryptografische Debatte für Bereiche wie TLS-Schlüsselaustausch oder digitale Signaturen, wo das NIST im Status-Report zur vierten Runde der Standardisierung auch Verfahren wie CRYSTALS-Dilithium (ML-DSA), Falcon (FN-DSA) und SPHINCS+ (SLH-DSA) bewertet. Für Passwort-Hashing bleibt die eigentliche Baustelle also eine klassische: ausreichend hohe Arbeitsfaktoren und Speicherhärte gegen immer leistungsfähigere klassische Angriffshardware, nicht gegen Quantencomputer.

Das Urteil: Welcher Algorithmus gewinnt 2026?

Auf Basis der aktuellen OWASP-Empfehlung und der hier zusammengetragenen Benchmarks fällt das Urteil für neue Systeme eindeutig aus: Argon2id ist 2026 die richtige Standardwahl. Es bietet die höchste Gesamtresistenz gegen GPU-, ASIC- und Seitenkanalangriffe, lässt sich über Speicher, Iterationen und Parallelität fein auf die eigene Infrastruktur abstimmen und liegt in den verglichenen Benchmarks bei vergleichbarer Sicherheit meist niedriger in der Latenz als scrypt.

scrypt bleibt eine solide zweite Wahl, vor allem dort, wo Argon2id technisch nicht verfügbar ist oder bereits eine etablierte scrypt-Infrastruktur existiert, etwa bei Schlüsselableitung für Verschlüsselung. Die gemessenen 265 Millisekunden pro Hash bei OWASP-Minimalparametern zeigen aber auch: Ohne sorgfältige Kapazitätsplanung kann scrypt bei hohem Anmeldeaufkommen zum Performance-Risiko werden.

bcrypt verdient seinen Platz in der Geschichte der Kryptografie, ist aber 2026 kein Verfahren mehr, das man für ein neues System aktiv auswählen sollte. Für bestehende Systeme mit großer Nutzerbasis ist ein sofortiger Umstieg selten praktikabel – hier gilt die Kombination aus angehobenem Cost-Faktor und einer Rehash-on-Login-Migration zu Argon2id als pragmatischer Mittelweg, den auch mehrere der hier zitierten Entwickler-Leitfäden empfehlen.

Zusammengefasst lässt sich die Entscheidung auf eine einfache Faustregel herunterbrechen: Neue Projekte starten mit Argon2id und den OWASP-Startparametern, messen die reale Latenz auf eigener Hardware und passen danach fein nach. Bestehende Systeme mit bcrypt erhöhen zunächst den Cost-Faktor auf mindestens 12 und planen parallel die schrittweise Migration. scrypt bleibt dort sinnvoll, wo es bereits etabliert ist oder Argon2id technisch nicht zur Verfügung steht, etwa in älteren Embedded-Umgebungen. Keines der drei Verfahren ersetzt zusätzliche Schutzmaßnahmen wie Rate-Limiting, Multi-Faktor-Authentifizierung oder Monitoring – Passwort-Hashing ist eine notwendige, aber keine hinreichende Sicherheitsmaßnahme.

Häufige Fragen zu Argon2id, bcrypt und scrypt

Ist Argon2id immer knack-resistenter als bcrypt?
Bei vergleichbaren, aktuellen OWASP-Parametern bietet Argon2id durch seine Speicherhärte einen höheren Widerstand gegen Offline-Angriffe mit GPUs oder ASICs als bcrypt, weil parallele Angriffsversuche zusätzlich teuren Speicher benötigen statt nur Rechenzeit. Wird Argon2id dagegen mit sehr niedrigen, nicht-OWASP-konformen Parametern konfiguriert, etwa um Latenz um jeden Preis zu minimieren, kann der Sicherheitsvorteil gegenüber einem bcrypt mit hohem Cost-Faktor schrumpfen oder ganz verschwinden. Die Parameterwahl ist deshalb mindestens so wichtig wie die Wahl des Algorithmus selbst.

Kann ich bcrypt einfach durch Argon2id ersetzen, ohne die Datenbank zu ändern?
Nein. Bestehende bcrypt-Hashes lassen sich nicht in Argon2id umrechnen. Der gängige Weg ist eine Rehash-on-Login-Migration, bei der neue Argon2id-Hashes erst beim nächsten erfolgreichen Login eines Nutzers erzeugt werden.

Warum hat bcrypt ein Limit von 72 Byte?
Das Limit ergibt sich aus der zugrunde liegenden Blowfish-Chiffre, auf der bcrypt basiert. Passwörter oder Passphrasen, die länger als 72 Byte sind, müssen im Anwendungscode vorab behandelt werden, etwa durch Vorhashen mit einer Hashfunktion, statt sie stillschweigend abschneiden zu lassen.

Ist scrypt sicherer als Argon2id, weil es älter und länger erprobt ist?
Nicht grundsätzlich. scrypt ist speicherhart und solide, aber Argon2id wurde als direkte Weiterentwicklung konzipiert und kombiniert Speicherhärte mit zusätzlicher Resistenz gegen Seitenkanalangriffe. OWASP führt deshalb Argon2id als erste Empfehlung, scrypt als Alternative.

Wie wähle ich die richtigen Argon2id-Parameter für meinen Server?
Mit den OWASP-Startwerten (19 MiB, 2 Iterationen, Parallelität 1) beginnen, dann auf der tatsächlichen Produktionshardware die Latenz messen und Speicher oder Iterationen so anpassen, dass ein einzelner Hash-Vorgang eine für die Nutzer akzeptable, aber für Angreifer teure Zeitspanne benötigt.

Macht ein Quantencomputer Argon2id, bcrypt oder scrypt unsicher?
Nein. Die 2024 vom NIST finalisierten Post-Quanten-Standards betreffen vor allem asymmetrische Verfahren wie Schlüsselaustausch und digitale Signaturen. Symmetrische Hash- und KDF-Konstruktionen wie Argon2id, bcrypt und scrypt sind von Quantenalgorithmen wie Shors Algorithmus nicht in vergleichbarer Weise betroffen.

Welches Verfahren eignet sich für Serverless-Umgebungen am besten?
Argon2id mit reduziertem Speicherparameter ist meist die beste Balance, weil es sich flexibel an enge Speicherbudgets anpassen lässt. scrypt ist wegen seines hohen OWASP-Minimalspeichers von etwa 128 MiB in stark speicherbeschränkten Funktionsinstanzen oft weniger praktikabel, und bcrypt kommt dort nur dann infrage, wenn das geringere Sicherheitsniveau ausdrücklich akzeptiert wird.

Lohnt sich eine Migration zu Argon2id auch für kleine Projekte mit wenigen Nutzern?
Ja. Der Implementierungsaufwand ist überschaubar, viele moderne Frameworks und Bibliotheken unterstützen Argon2id bereits nativ, und gerade bei kleinen Projekten lässt sich eine Migration ohne komplexe Lastüberlegungen deutlich einfacher und schneller umsetzen als bei Systemen mit Millionen Nutzerdatensätzen.

Reicht Passwort-Hashing allein aus, um Nutzerkonten zu schützen?
Nein. Passwort-Hashing schützt vor allem gegen Offline-Angriffe nach einem Datenbank-Diebstahl. Gegen Online-Angriffe wie Credential Stuffing oder Brute-Force direkt über die Login-API braucht es zusätzlich Rate-Limiting, Multi-Faktor-Authentifizierung und eine Überwachung auffälliger Anmeldemuster. Ein starkes Hash-Verfahren ist damit ein notwendiger Baustein in einer mehrschichtigen Sicherheitsstrategie, aber niemals der einzige.