Wer 2026 ein neues Login-System baut, stolpert früher oder später über dieselbe Frage: bcrypt oder Argon2id? Beide Algorithmen tauchen in praktisch jeder Bibliothek für Passwort-Hashing auf, aber sie stammen aus unterschiedlichen Epochen der IT-Sicherheit. bcrypt kam 1999 aus dem Umfeld von OpenBSD, Argon2 gewann 2015 die Password Hashing Competition und ist inzwischen als RFC 9106 standardisiert. Für Entwicklerinnen und Entwickler in Deutschland, Österreich und der Schweiz, die gerade eine neue Anwendung planen oder ein altes Login-System modernisieren, ist die Wahl kein akademisches Detail. Sie entscheidet darüber, wie teuer ein Angriff auf gestohlene Passwort-Hashes für Kriminelle wird.

Dieser Vergleich zeigt, wo die beiden Algorithmen technisch auseinanderliegen, welche Parameter OWASP 2026 empfiehlt, was Benchmarks aus drei unabhängigen Quellen zeigen und wie eine Migration von bcrypt auf Argon2id in der Praxis abläuft. Am Ende steht ein klares Urteil mit Zahlen, keine vage Empfehlung.

bcrypt vs. Argon2id: Die Kernfrage in drei Sätzen

bcrypt ist ein bewährter, gut erforschter Blowfish-basierter Hashing-Algorithmus mit einem einzigen Kostenfaktor. Argon2id ist ein memory-hardes Verfahren mit drei einstellbaren Parametern (Speicher, Zeit, Parallelität) und gilt seit der Password Hashing Competition 2015 als moderner Goldstandard. Der Unterschied läuft im Kern auf eine Frage hinaus: Wie teuer soll es für Angreifer mit GPU-Clustern werden, gestohlene Hashes zu knacken? Argon2id beantwortet das deutlich besser, weil es nicht nur Rechenzeit, sondern auch Arbeitsspeicher verlangt, den man bei Grafikkarten nicht beliebig skalieren kann.

Für neue Projekte ist die Antwort in den meisten aktuellen Leitfäden eindeutig: Argon2id zuerst prüfen, bcrypt nur dort belassen, wo Migrationskosten den Sicherheitsgewinn kurzfristig übersteigen. Genau diese Abwägung ist der rote Faden dieses Artikels.

Was ist bcrypt? Herkunft und Funktionsweise

bcrypt wurde 1999 von Niels Provos und David Mazières für OpenBSD entwickelt und basiert auf einer modifizierten Version der Blowfish-Verschlüsselung, dem sogenannten Eksblowfish-Setup. Der Algorithmus wiederholt die Schlüsselexpansion mehrfach, gesteuert über einen Kostenfaktor (cost factor), der die Anzahl der Iterationen exponentiell erhöht. Ein cost von 12 bedeutet 2^12, also 4.096 Runden.

Diese Einfachheit ist gleichzeitig Stärke und Schwäche. bcrypt braucht praktisch keinen Arbeitsspeicher, nur wenige Kilobyte, was es auf ressourcenarmer Hardware attraktiv macht. Genau das ist aber auch das Problem: Weil bcrypt kaum Speicher benötigt, lässt sich der Algorithmus auf spezialisierter Hardware wie FPGAs oder GPU-Farmen parallelisieren. Ein Angreifer mit tausenden GPU-Kernen kann viele bcrypt-Hashes gleichzeitig durchprobieren, weil jeder einzelne Rechenkern nur ein paar Kilobyte Speicher braucht.

Ein weiterer praktischer Nachteil: bcrypt schneidet Passwörter nach 72 Bytes ab. Alles danach wird stillschweigend ignoriert, was in seltenen Fällen zu Sicherheitslücken führt, wenn Entwickler das nicht wissen und lange Passphrasen erwarten, die tatsächlich vollständig geprüft werden. Trotzdem ist bcrypt bis heute in Millionen Systemen im Einsatz, von Ruby on Rails über PHP bis zu unzähligen Legacy-Anwendungen, weil es seit 27 Jahren keine praktikable Kollisions- oder Umkehrattacke gegen den Algorithmus selbst gibt.

Interessant ist auch, wie bcrypt seinen Hash-String aufbaut: Das Ergebnis enthält, für Menschen lesbar, das verwendete Präfix (etwa $2b$), den Kostenfaktor, den Salt und den eigentlichen Hash, alles in einem einzigen Textstring. Diese Selbstbeschreibung ist ein praktischer Vorteil, den Argon2id übernommen hat: Beim Aktualisieren des Kostenfaktors müssen alte Hashes nicht sofort neu berechnet werden, die Anwendung kann den im Hash gespeicherten Parameter erkennen und bei Bedarf gezielt migrieren, ohne den kompletten Bestand auf einen Schlag umstellen zu müssen.

Was ist Argon2id? Der PHC-Gewinner im Detail

Argon2 wurde von Alex Biryukov, Daniel Dinu und Dmitry Khovratovich an der Universität Luxemburg entwickelt und setzte sich 2015 gegen 23 andere Einreichungen bei der Password Hashing Competition durch, wie heise.de damals berichtete. Es gibt drei Varianten: Argon2d ist optimiert gegen GPU-Angriffe, aber anfällig für Seitenkanalangriffe. Argon2i schützt gegen Seitenkanäle, ist aber schwächer gegen reine Rechenkraft. Argon2id kombiniert beide Ansätze und ist seit 2021 in RFC 9106 als empfohlener Standard für Passwort-Hashing festgeschrieben.

Der entscheidende Unterschied zu bcrypt liegt in drei einstellbaren Parametern: Speicherkosten (memory cost, m), Zeitkosten (time cost, t) und Parallelitätsgrad (p). Ein typischer Wert für 2026 sieht laut aktuellen Guides so aus: m=19456 KiB, t=2, p=1 als OWASP-Basiskonfiguration, oder m=64 MiB, t=3, p=1 für höhere Sicherheitsanforderungen. Der Speicherbedarf ist der Clou: Ein Angreifer, der Millionen Hashes parallel knacken will, braucht dafür auch Millionen mal 19 bis 64 MiB Arbeitsspeicher gleichzeitig. Das sprengt selbst große GPU-Cluster schnell, weil Grafikspeicher im Vergleich zu Rechenkernen knapp und teuer ist.

Argon2id hat außerdem keine praktische Längenbegrenzung wie bcrypt und gilt laut OWASP Cheat Sheet Series als Standardempfehlung für neue Anwendungen. Der Preis dafür: Argon2id braucht mehr Implementierungssorgfalt, weil drei statt einem Parameter richtig kalibriert werden müssen. Wer die Parameter falsch setzt, etwa Speicher zu niedrig oder Parallelität zu hoch für die verfügbare Serverhardware, verliert einen Teil des Sicherheitsgewinns wieder, ohne es sofort zu bemerken, da der Algorithmus trotzdem funktioniert, nur eben schwächer als beabsichtigt.

Technische Spezifikationen im direkten Vergleich

Die folgende Tabelle stellt die wichtigsten technischen Eigenschaften beider Algorithmen gegenüber, basierend auf aktuellen 2026er-Vergleichsguides und der offiziellen RFC-Spezifikation.

KriteriumbcryptArgon2id
Veröffentlichung1999 (USENIX)2015 (PHC-Sieger)
StandardisierungDe-facto-Standard, kein RFCRFC 9106 (2021)
Basis-AlgorithmusModifiziertes Blowfish (Eksblowfish)Eigenständige Konstruktion, memory-hard
Einstellbare Parameter1 (cost factor)3 (memory, time, parallelism)
Speicherbedarf~4 KB, fixKonfigurierbar, typ. 19–128 MiB
Memory-hardNeinJa
GPU-/ASIC-ResistenzMittelHoch
Seitenkanal-ResistenzGut (constant-time)Gut (id-Modus kombiniert d+i)
Maximale Passwortlänge72 Bytes (Abschneiden danach)Keine praktische Begrenzung
OWASP-Empfehlung 2026Akzeptabel für Legacy-SystemeErste Wahl für neue Systeme
Verbreitung in StandardbibliothekenSehr hoch (PHP, Ruby, Node.js, Java)Hoch und wachsend (PHP 7.2+, libsodium, Go)
ImplementierungsaufwandNiedrigMittel

Benchmarks: Was sagen unabhängige Messungen?

Zahlen sind bei Hashing-Algorithmen wichtiger als Marketing-Aussagen. Drei aktuelle 2026er-Quellen liefern vergleichbare, aber nicht identische Messwerte, was typisch ist, weil Hashzeiten stark von der zugrunde liegenden Hardware abhängen.

Nach Angaben von Deepak Guptas Password-Hashing-Framework für 2026 liegt bcrypt mit cost=12 bei rund 250 bis 400 Millisekunden pro Hash, Argon2id mit m=64 MiB und t=3 landet bei etwa 180 bis 200 Millisekunden. Bei niedrigeren Speicherkosten (m=19 MiB, t=2) sinkt die Zeit auf 55 bis 60 Millisekunden. Ein zweiter Guide von go-tools.org bestätigt diese Größenordnung und empfiehlt m=19456 KiB, t=2, p=1 als Standardkonfiguration für neue Projekte, mit bcrypt cost=12 als Minimum für Legacy-Systeme, die nicht sofort migriert werden können.

Der französisch-deutsche Vergleichsdienst cdrn.fr kommt in seiner 2026er-Analyse zu einem ähnlichen Bild: bcrypt braucht rund 4 KiB Speicher unabhängig vom Kostenfaktor, während Argon2id bei empfohlenen 19 MiB Speicherverbrauch etwa das 4.750-fache an RAM pro Hash-Vorgang benötigt. Genau dieser Speicherhunger ist der Punkt, an dem Argon2id gegen GPU-Farmen gewinnt: Ein Angreifer mit 1.000 GPU-Kernen kann theoretisch 1.000 bcrypt-Hashes parallel probieren, aber nur so viele Argon2id-Hashes, wie der verfügbare GPU-Speicher an 19-MiB-Blöcken hergibt, oft deutlich weniger als 100 gleichzeitig auf Consumer-Grafikkarten.

KonfigurationHashzeitSpeicherverbrauchQuelle
bcrypt, cost=10~65–100 ms<1 MBDeepak Gupta Framework 2026
bcrypt, cost=12~250–400 ms<1 MBDeepak Gupta Framework 2026
bcrypt, cost=13~500 ms4 KBGuptadeepak Decision Framework
Argon2id, m=19 MiB, t=2, p=1~55–60 ms19 MiBgo-tools.org
Argon2id, m=64 MiB, t=3, p=1~180–200 ms64 MiBDeepak Gupta Framework 2026
Argon2id, m=128 MiB, t=3, p=4~150 ms128 MiBDeepak Gupta Framework 2026

Die Kernaussage aller drei Quellen deckt sich: Bei vergleichbarer Hashzeit (rund 200 Millisekunden) verlangt Argon2id ein Vielfaches an Speicher gegenüber bcrypt, was Angriffe mit spezialisierter Hardware massiv verteuert. Genau das ist der Grund, warum OWASP in der Password Storage Cheat Sheet Series Argon2id als Standard für neue Anwendungen führt.

OWASP- und Behördenempfehlungen 2026

OWASP nennt in der aktuellen Cheat-Sheet-Fassung Argon2id als erste Wahl für neue Projekte, mit bcrypt als akzeptabler Alternative, wenn Argon2 aus technischen Gründen nicht verfügbar ist, etwa in älteren Sprach-Runtimes ohne native Bibliotheken. Für Argon2id nennt OWASP zwei gängige Parametersätze: entweder m=19456 (19 MiB), t=2, p=1, oder m=47104 (46 MiB), t=1, p=1 für schnellere, aber weniger speicherintensive Hashes.

Das deutsche Bundesamt für Sicherheit in der Informationstechnik (BSI) äußert sich in seinen Empfehlungen zwar primär zu Zwei-Faktor-Verfahren, betont aber grundsätzlich, dass reine Passwort-Hashes allein keinen ausreichenden Kontoschutz mehr bieten und mit einem zweiten Faktor kombiniert werden sollten, unabhängig vom gewählten Hashing-Algorithmus. Das NIST SP 800-63B, der US-Standard für digitale Identität, verlangt seit Jahren, dass gespeicherte Passwörter mit einem “memory-hard”-Verfahren oder mindestens 10.000 Iterationen eines Schlüsselableitungsverfahrens gehasht werden, ein Kriterium, das Argon2id von Haus aus erfüllt und bcrypt nur über hohe Kostenfaktoren erreicht.

Auch der französische Sicherheitsdienstleister ANSSI und das österreichische CERT verweisen in ihren technischen Leitfäden auf dieselben internationalen Standards, es gibt keine abweichende DACH-spezifische Hashing-Empfehlung. Das vereinfacht die Umsetzung für Unternehmen, die in mehreren deutschsprachigen Ländern gleichzeitig aktiv sind: Eine einzige, an OWASP und RFC 9106 orientierte Konfiguration erfüllt die technischen Erwartungen in Deutschland, Österreich und der Schweiz gleichermaßen, ohne länderspezifische Sonderlösungen entwickeln zu müssen.

Preisvergleich: Rechenkosten in der Cloud

Passwort-Hashing kostet kein Geld für eine Lizenz, aber es kostet Rechenzeit, und Rechenzeit kostet in Cloud-Umgebungen echtes Geld. Die folgende Tabelle schätzt die Infrastrukturkosten für 1 Million Login-Hashes pro Monat auf Basis typischer Cloud-Instanzpreise (vCPU-Stunden), um die praktische Kostendifferenz zwischen beiden Verfahren einzuordnen.

SzenarioAlgorithmusCPU-Zeit / LoginRelative Betriebskosten
Startup, kleine Nutzerbasisbcrypt cost=10~80 msNiedrig
Startup, kleine NutzerbasisArgon2id m=19 MiB, t=2~58 msNiedrig, zusätzlicher RAM-Bedarf
Mittelständisches SaaSbcrypt cost=12~300 msMittel
Mittelständisches SaaSArgon2id m=64 MiB, t=3~190 msMittel, höherer RAM je Instanz
Enterprise, hohe Login-Frequenzbcrypt cost=13~500 msHoch
Enterprise, hohe Login-FrequenzArgon2id m=128 MiB, t=3, p=4~150 msMittel-Hoch, mehr RAM, aber weniger CPU-Zeit

Wichtig für die Kalkulation: bcrypt-Kosten laufen fast ausschließlich über CPU-Zeit, Argon2id verschiebt einen Teil der Last auf Arbeitsspeicher. In Cloud-Umgebungen mit knapp bemessenem RAM pro Instanz (etwa kleine Container oder Serverless-Funktionen) kann das bei hoher Parallelität an Login-Endpunkten zu Speicherengpässen führen, wenn nicht sauber dimensioniert wird. Für die meisten Anwendungen mit einigen tausend bis einigen hunderttausend Logins pro Tag ist der Unterschied in absoluten Euro-Beträgen jedoch gering, typischerweise im Bereich weniger Euro pro Monat an zusätzlicher Rechenzeit oder Arbeitsspeicher.

Sicherheit gegen moderne Angriffsszenarien

Der wichtigste Unterschied zeigt sich nicht im Normalbetrieb, sondern wenn eine Datenbank mit Passwort-Hashes gestohlen wird. Genau für dieses Szenario ist Passwort-Hashing überhaupt gedacht. Bei einem Offline-Angriff mit GPU-Clustern zeigt sich der Vorteil von Argon2id am deutlichsten: Weil jeder Hash-Versuch mehrere Megabyte Speicher braucht, lässt sich die Angriffsgeschwindigkeit nicht linear mit mehr GPU-Kernen skalieren, wie es bei bcrypt der Fall ist.

Für ASIC- und FPGA-basierte Angriffe gilt Ähnliches: Spezialisierte Hashing-Chips, wie sie beim Bitcoin-Mining oder bei manchen Passwort-Cracking-Rigs eingesetzt werden, sind auf schnelle, speicherarme Berechnungen optimiert. Genau das macht sie gegen bcrypt effektiver als gegen Argon2id, wo der Speicherbedarf die Chip-Fläche pro Recheneinheit unwirtschaftlich groß macht. Seitenkanalangriffe, bei denen Angreifer über Cache-Timing oder Stromverbrauch Rückschlüsse auf Passwörter ziehen, betreffen beide Algorithmen im geringeren Maße, wobei der id-Modus von Argon2 speziell für diesen Anwendungsfall entwickelt wurde und sowohl daten-unabhängige als auch daten-abhängige Speicherzugriffe kombiniert.

Ein oft unterschätztes Angriffsszenario ist Credential Stuffing, bei dem Angreifer Passwort-Kombinationen aus früheren, ganz anderen Datenlecks automatisiert gegen ein Login-Formular testen. Hier hilft weder bcrypt noch Argon2id direkt, weil der Angriff online über das Login-Formular läuft, nicht offline gegen die eigene Hash-Datenbank. Trotzdem verringert ein starker Hashing-Algorithmus indirekt die Wahrscheinlichkeit, dass die eigenen Nutzerdaten überhaupt erst in einem der Leaks landen, die für Credential Stuffing gegen andere Dienste genutzt werden, wenn irgendwann doch einmal eine Datenbank kompromittiert wird. Wörterbuchangriffe mit vorgefertigten Listen häufiger Passwörter, wie sie Tools wie Hashcat einsetzen, sind gegen beide Algorithmen möglich, aber gegen Argon2id durch den Speicherbedarf deutlich langsamer als gegen bcrypt bei identischer Hashzeit.

Wer nutzt was: bcrypt und Argon2id in bekannter Software

Theorie ist das eine, tatsächliche Produktentscheidungen etwas anderes. Ein Blick auf verbreitete Frameworks und Tools zeigt, wie uneinheitlich der Umstieg auf Argon2id in der Praxis verläuft, selbst 2026, elf Jahre nach dem PHC-Sieg.

  • Ruby on Rails: has_secure_password nutzt standardmäßig weiterhin bcrypt über die Gem bcrypt, gilt in der Rails-Community als bewährt und wird bei den meisten Anwendungen nicht ohne triftigen Grund ausgetauscht.
  • Laravel (PHP): Bietet seit mehreren Major-Versionen sowohl bcrypt als auch Argon2id nativ über die Hash-Fassade an, mit Argon2id als konfigurierbarer Alternative, die in der offiziellen Dokumentation ausdrücklich empfohlen wird.
  • Django (Python): Verwendet standardmäßig PBKDF2, unterstützt aber Argon2id als bevorzugten Hasher, sobald das Paket argon2-cffi installiert ist, und empfiehlt genau das in der eigenen Sicherheitsdokumentation für neue Projekte.
  • Symfony (PHP): Wählt seit einigen Versionen automatisch den stärksten verfügbaren Algorithmus, in der Praxis meist Argon2id via libsodium, wenn die PHP-Umgebung das unterstützt, mit bcrypt als Fallback.
  • Authelia: Der quelloffene Authentifizierungs-Proxy für Self-Hosting-Umgebungen setzt Argon2id als Standardalgorithmus für die interne Nutzerverwaltung ein und begründet das explizit mit der Speicherhärte gegenüber bcrypt.
  • Keycloak: Das Identity-and-Access-Management-Tool von Red Hat unterstützt mehrere Hashing-Algorithmen konfigurierbar, PBKDF2 ist historisch der Default, Argon2 lässt sich über die Admin-Konsole aktivieren.

Das Muster ist erkennbar: Jüngere, sicherheitsfokussierte Projekte wie Authelia setzen von Anfang an auf Argon2id. Ältere, etablierte Frameworks wie Rails halten aus Kompatibilitätsgründen länger an bcrypt fest, bieten aber zunehmend Argon2id als Option an. Für Entwicklerinnen und Entwickler bedeutet das: Wer ein modernes Framework wählt, bekommt Argon2id oft schon vorkonfiguriert, wer auf einer älteren Codebasis arbeitet, muss aktiv nachrüsten.

Die Kostenrechnung hinter Brute-Force-Angriffen

Um zu verstehen, warum der Speicherbedarf von Argon2id in der Praxis so viel bewirkt, hilft eine vereinfachte Rechnung. Angenommen, ein Angreifer verfügt über eine High-End-Grafikkarte mit 24 GB VRAM. Für bcrypt-Hashes, die praktisch keinen Speicher benötigen, limitiert fast ausschließlich die Rechenleistung der GPU die Anzahl paralleler Versuche, was auf modernen Karten viele tausend Hashes pro Sekunde erlaubt, je nach Kostenfaktor.

Bei Argon2id mit m=64 MiB sieht die Rechnung anders aus: 24 GB VRAM geteilt durch 64 MiB ergibt rechnerisch maximal rund 375 parallele Instanzen, bevor der Speicher der Karte ausgeschöpft ist, unabhängig davon, wie viele Rechenkerne die GPU sonst hätte. Die Recheneinheiten der Karte bleiben also größtenteils ungenutzt, weil nicht die Rechenleistung, sondern der Speicher der limitierende Faktor ist. Genau das ist der Effekt, den memory-hard-Algorithmen erzielen sollen: Sie zwingen Angreifer, in teuren Speicher statt in günstige Rechenkerne zu investieren, und Speicher lässt sich in spezialisierter Angriffs-Hardware deutlich schlechter skalieren als reine Rechenleistung.

Diese Überlegung ist auch der Grund, warum Kryptowährungs-Mining-ASICs, die für SHA-256 oder ähnliche speicherarme Funktionen gebaut wurden, gegen Argon2id wirkungslos sind. Ein ASIC-Design für Argon2id müsste pro Recheneinheit 19 bis 128 MiB eigenen Speicher mitbringen, was die Chipfläche und damit die Herstellungskosten pro paralleler Angriffseinheit massiv erhöht, verglichen mit einem bcrypt-optimierten Chip.

Implementierung in weiteren Programmiersprachen

Neben Node.js ist Argon2id in praktisch jeder modernen Sprache verfügbar. In Python übernimmt das Paket argon2-cffi die Arbeit, das auch Django intern nutzt, wenn Argon2id als Hasher konfiguriert ist.

from argon2 import PasswordHasher

ph = PasswordHasher(memory_cost=19456, time_cost=2, parallelism=1)
hash_value = ph.hash("mein-passwort")
ph.verify(hash_value, "mein-passwort")

In PHP ist Argon2id seit Version 7.2 direkt in der Standardbibliothek verfügbar, ganz ohne externe Abhängigkeit, über die Funktion password_hash mit der Konstante PASSWORD_ARGON2ID.

$hash = password_hash($password, PASSWORD_ARGON2ID, [
    'memory_cost' => 19456,
    'time_cost'   => 2,
    'threads'     => 1,
]);
password_verify($password, $hash);

Go-Entwickler greifen in der Regel auf das offizielle Paket golang.org/x/crypto/argon2 zurück, das direkt vom Go-Team gepflegt wird und damit eine vertrauenswürdige Referenzimplementierung darstellt. Java-Projekte nutzen meist die Bibliothek Bouncy Castle oder den Argon2-Wrapper von Spring Security, das seit einigen Versionen Argon2id als empfohlenen PasswordEncoder listet.

Rechtlicher und regulatorischer Kontext in Deutschland und der EU

Für Unternehmen in Deutschland und der DACH-Region ist Passwort-Hashing nicht nur eine technische, sondern auch eine rechtliche Frage. Die DSGVO verlangt in Artikel 32 “geeignete technische und organisatorische Maßnahmen” nach dem “Stand der Technik”, ohne konkrete Algorithmen vorzuschreiben. In der Praxis orientieren sich deutsche Aufsichtsbehörden und Prüfer an den Empfehlungen von BSI, OWASP und NIST, wodurch ein veraltetes Hashing-Verfahren im Schadensfall (etwa nach einem Datenbank-Diebstahl) zum Haftungsrisiko werden kann, wenn erkennbar war, dass stärkere Alternativen wie Argon2id verfügbar und Stand der Technik waren.

Der Cyber Resilience Act der EU, der schrittweise in Kraft tritt, verlangt zusätzlich von Herstellern vernetzter Produkte, Sicherheitslücken über den gesamten Produktlebenszyklus zu vermeiden und zu melden. Ein unzureichend konfigurierter Passwort-Hash, der bekannte Schwächen aufweist, fällt unter diese Sorgfaltspflicht. Für Entwicklerteams in DACH-Unternehmen ist die Umstellung auf Argon2id damit auch ein Baustein, um regulatorische Anforderungen nachweisbar zu erfüllen, nicht nur ein rein technisches Detail.

Fünf reale Einsatzszenarien

Die Wahl zwischen bcrypt und Argon2id hängt stark vom konkreten Kontext ab. Hier fünf Szenarien aus der Praxis, mit klarer Empfehlung.

  • Neues SaaS-Produkt ohne Altlasten: Argon2id direkt einsetzen, etwa mit m=19456 KiB, t=2, p=1 als Startkonfiguration. Es gibt keinen Grund, 2026 noch mit bcrypt zu starten, wenn die verwendete Sprache eine gepflegte Argon2-Bibliothek mitbringt.
  • Bestehende Rails- oder Django-Anwendung mit Millionen Nutzerkonten: bcrypt bleibt vorerst im Einsatz, aber mit erhöhtem Kostenfaktor (mindestens 12) und einem klaren Migrationsplan bei jedem Login (Rehash-on-Login-Strategie, siehe Migrationsleitfaden unten).
  • IoT-Gerät oder Embedded-System mit wenig RAM: bcrypt kann hier praktikabler sein, weil Argon2id mit sinnvollen Speicherparametern schnell an Hardwaregrenzen stößt. Wo genug RAM verfügbar ist, sollte trotzdem Argon2id mit reduzierten, aber sinnvollen Parametern (etwa m=8 MiB) geprüft werden.
  • Fintech- oder Banking-Anwendung mit hohen Compliance-Anforderungen: Argon2id mit hohen Parametern (m=64–128 MiB, t=3) plus verpflichtende Zwei-Faktor-Authentifizierung, da einzelne Hashing-Stärke allein regulatorische Vorgaben selten vollständig erfüllt.
  • Open-Source-Projekt mit vielen unterschiedlichen Deployment-Umgebungen: Argon2id als Default, mit bcrypt als Fallback für Umgebungen ohne native Argon2-Unterstützung, klar dokumentiert in der Konfigurationsdatei.

Code-Beispiel: Argon2id in Node.js implementieren

Die Bibliothek argon2 für Node.js kapselt die native Implementierung und macht den Umstieg unkompliziert. Das folgende Beispiel zeigt eine typische OWASP-konforme Konfiguration:

const argon2 = require('argon2');

async function hashPassword(password) {
  return argon2.hash(password, {
    type: argon2.argon2id,
    memoryCost: 19456, // 19 MiB, OWASP-Basiswert 2026
    timeCost: 2,
    parallelism: 1,
  });
}

async function verifyPassword(hash, password) {
  return argon2.verify(hash, password);
}

Zum Vergleich die entsprechende bcrypt-Implementierung mit der weit verbreiteten bcryptjs-Bibliothek:

const bcrypt = require('bcryptjs');

async function hashPassword(password) {
  const salt = await bcrypt.genSalt(12); // cost factor 12
  return bcrypt.hash(password, salt);
}

async function verifyPassword(hash, password) {
  return bcrypt.compare(password, hash);
}

Migrationsleitfaden: Von bcrypt zu Argon2id

Ein bestehendes System mit Millionen bcrypt-Hashes lässt sich nicht auf einen Schlag umstellen, weil die ursprünglichen Klartext-Passwörter nicht mehr vorliegen. Der Standardweg ist eine schrittweise Migration, die bei jedem erfolgreichen Login ausgelöst wird.

  1. Argon2-Bibliothek installieren und in einer Staging-Umgebung testen (bei Node.js: npm install argon2).
  2. Datenbankschema erweitern, um sowohl bcrypt- als auch Argon2id-Hashes zu unterstützen, meist über ein zusätzliches Feld hash_algorithm.
  3. Login-Logik anpassen: Beim Einloggen zunächst prüfen, welcher Algorithmus für den gespeicherten Hash verwendet wurde.
  4. Bei erfolgreicher bcrypt-Verifikation das Klartext-Passwort, das zu diesem Zeitpunkt im Speicher vorliegt, sofort mit Argon2id neu hashen.
  5. Den neuen Argon2id-Hash in der Datenbank speichern und das Feld hash_algorithm aktualisieren.
  6. Für inaktive Konten, die sich lange nicht einloggen, ein Ablaufdatum setzen und nach Fristablauf ein Passwort-Reset erzwingen.
  7. Monitoring einbauen, das den Anteil migrierter Konten laufend trackt (Ziel: Vollständige Migration typischerweise nach 6 bis 18 Monaten, abhängig von der Login-Frequenz der Nutzerbasis).
  8. Nach Erreichen einer hohen Migrationsquote (üblich sind 90 % oder mehr) den bcrypt-Verifikationspfad als deprecated markieren, aber nicht sofort entfernen.
  9. Verbleibende bcrypt-Konten gezielt per E-Mail zu einem Passwort-Reset auffordern, um die Migration abzuschließen.

Diese Rehash-on-Login-Strategie ist der in der Praxis am häufigsten dokumentierte Ansatz und vermeidet ein riskantes Massen-Reset aller Passwörter auf einen Schlag.

Ein Punkt, der in vielen Migrationsleitfäden zu kurz kommt: Die doppelte Verifikationslogik (bcrypt UND Argon2id gleichzeitig im Code) sollte von Anfang an mit Tests abgesichert werden, die beide Pfade abdecken, nicht nur den neuen. Es ist leicht, versehentlich den alten bcrypt-Pfad durch ein Refactoring zu brechen, während man am neuen Argon2id-Code arbeitet, was bestehende Nutzer beim nächsten Login aussperren würde. Ein cleaner Ansatz kapselt beide Algorithmen hinter einer gemeinsamen Schnittstelle, etwa einer Funktion verifyAndMaybeRehash(hash, password), die die Unterscheidung intern übernimmt und für den restlichen Anwendungscode transparent bleibt. So bleibt die Login-Logik unabhängig vom konkreten Algorithmus lesbar, und ein späterer weiterer Wechsel, etwa zu einem zukünftigen Nachfolgealgorithmus, lässt sich über dieselbe Struktur abbilden.

Für Teams, die keine Kontrolle über den Zeitpunkt der Migration einzelner Nutzer haben, etwa bei B2B-Software mit seltenen Logins von Admin-Konten, empfiehlt sich zusätzlich ein Batch-Job, der inaktive bcrypt-Konten nach einer festgelegten Frist proaktiv zu einem Passwort-Reset auffordert, statt unbegrenzt auf den nächsten Login zu warten. Das verhindert, dass Jahre nach der eigentlichen Umstellung noch vereinzelte bcrypt-Hashes im System verbleiben.

Performance-Tests vor dem Produktivbetrieb

Bevor eine Argon2id- oder bcrypt-Konfiguration produktiv geht, lohnt sich ein Lasttest unter realistischen Bedingungen, nicht nur ein einzelner Hash-Aufruf auf dem Entwicklerlaptop. Ein sinnvoller Test misst drei Dinge gleichzeitig: die durchschnittliche Hashzeit unter paralleler Last (etwa 50 gleichzeitige Login-Versuche), den Speicherverbrauch der Anwendung insgesamt während dieser Last, und die p99-Latenz, also die Zeit, die 99 % aller Anfragen nicht überschreiten. Gerade bei Argon2id kann der Speicherverbrauch bei vielen parallelen Logins schnell in den Gigabyte-Bereich wachsen, wenn Parallelität und Nutzerlast nicht sauber gegeneinander abgewogen werden.

Ein praktikabler Richtwert, den mehrere 2026er-Guides nennen: Die Zielzeit für einen einzelnen Hash-Vorgang sollte zwischen 100 und 500 Millisekunden liegen, lang genug, um Angriffe zu verlangsamen, kurz genug, um legitime Nutzer nicht spürbar zu frustrieren. Wird dieser Korridor bei einem Lasttest deutlich überschritten, etwa weil der Anwendungsserver während einer Marketingkampagne plötzlich zehnmal mehr gleichzeitige Logins verarbeiten muss, sollte die Konfiguration angepasst werden, bevor es zu Timeouts oder Out-of-Memory-Abbrüchen im Produktivbetrieb kommt.

Monitoring-Tools wie Prometheus in Kombination mit Grafana eignen sich gut, um Hashzeit und Speicherverbrauch des Login-Endpunkts kontinuierlich zu beobachten. Ein plötzlicher Anstieg der durchschnittlichen Hashzeit kann außerdem ein früher Indikator für einen laufenden Credential-Stuffing- oder Brute-Force-Angriff sein, noch bevor klassische Rate-Limiting-Schwellenwerte greifen, weil die schiere Zahl paralleler Hashing-Operationen den Server zusätzlich unter Last setzt.

Vorteile und Nachteile im Überblick

bcrypt: Pro und Contra

  • Vorteil: 27 Jahre praktische Erprobung ohne bekannte praktikable Umkehrattacke.
  • Vorteil: Extrem geringer Speicherbedarf, ideal für ressourcenarme Umgebungen.
  • Vorteil: In praktisch jeder Programmiersprache und jedem Framework nativ verfügbar.
  • Nachteil: Nicht memory-hard, dadurch anfälliger für GPU- und ASIC-gestützte Angriffe.
  • Nachteil: Harte Grenze bei 72 Bytes Passwortlänge.
  • Nachteil: Nur ein einstellbarer Parameter, weniger Feinsteuerung möglich.

Argon2id: Pro und Contra

  • Vorteil: Memory-hard, dadurch deutlich teurer für GPU-/ASIC-Angriffe zu parallelisieren.
  • Vorteil: OWASP-Empfehlung für neue Systeme, RFC-standardisiert seit 2021.
  • Vorteil: Drei Parameter erlauben feine Abstimmung zwischen Sicherheit und Performance.
  • Vorteil: Keine praktische Längenbegrenzung bei Passwörtern.
  • Nachteil: Höherer Arbeitsspeicherbedarf kann bei hoher Login-Parallelität zu Engpässen führen.
  • Nachteil: Falsch konfigurierte Parameter (etwa zu niedriger Speicherwert) untergraben den Sicherheitsvorteil komplett.
  • Nachteil: Etwas geringere Verbreitung in sehr alten Sprach-Runtimes ohne aktive Pflege.

Häufige Implementierungsfehler

Ein Algorithmus ist nur so sicher wie seine Konfiguration. Bei bcrypt ist der häufigste Fehler ein zu niedriger Kostenfaktor, oft noch cost=10 oder niedriger aus alten Tutorials, obwohl 2026 mindestens cost=12 empfohlen wird. Bei Argon2id ist der klassische Fehler, die Speicherparameter drastisch zu senken, um Latenz zu sparen, etwa auf wenige Megabyte, wodurch der zentrale Vorteil gegenüber bcrypt verpufft.

Ein weiterer verbreiteter Fehler bei beiden Verfahren: Salting eigenständig implementieren, statt die eingebaute Salt-Generierung der jeweiligen Bibliothek zu nutzen. Sowohl bcrypt als auch Argon2id erzeugen automatisch einen zufälligen Salt pro Hash und speichern ihn im Ergebnisstring, ein eigenes Salt-Handling ist unnötig und fehleranfällig. Auch das Speichern von Passwort-Hashes ohne Rate-Limiting am Login-Endpunkt bleibt ein Problem, unabhängig vom gewählten Algorithmus, da Online-Brute-Force-Angriffe damit nicht ausgebremst werden.

Ein dritter, subtilerer Fehler betrifft die Fehlerbehandlung bei der Verifikation: Manche Implementierungen brechen die Passwortprüfung bei einem ungültigen Hash-Format mit einer Exception ab, statt konsistent “falsch” zurückzugeben. Das kann Angreifern über die Antwortzeit oder Fehlermeldung verraten, ob ein Nutzername überhaupt existiert, ein klassisches User-Enumeration-Problem, das unabhängig vom Hashing-Algorithmus behoben werden muss. Und schließlich: Viele Teams testen die gewählten Argon2id-Parameter nie unter realistischer Serverlast, sondern übernehmen ungeprüft Werte aus einem Blogartikel. Werte, die auf einer Entwicklermaschine mit viel freiem RAM gut funktionieren, können auf einem stark ausgelasteten Produktionsserver mit vielen gleichzeitigen Logins zu spürbaren Verzögerungen oder sogar Out-of-Memory-Fehlern führen.

Salting, Peppering und weitere Härtungsmaßnahmen

Ein Hashing-Algorithmus allein ist nur ein Teil einer soliden Passwort-Speicherung. Salting, also das Hinzufügen eines zufälligen, für jeden Hash einzigartigen Werts vor dem Hashen, verhindert, dass Angreifer vorberechnete Rainbow-Tables gegen mehrere Konten gleichzeitig einsetzen können. Sowohl bcrypt als auch Argon2id erledigen das automatisch: Der Salt wird zufällig erzeugt, mit dem Hash-Ergebnis verkettet gespeichert und bei der Verifikation automatisch wieder extrahiert. Entwickler müssen sich um diesen Schritt nicht manuell kümmern, ein eigenständiges Salt-Management ist bei modernen Bibliotheken überflüssig und erhöht nur das Fehlerrisiko.

Peppering geht einen Schritt weiter: Ein zusätzlicher, geheimer Wert, der nicht in der Datenbank, sondern separat (etwa in einem Secrets-Manager wie HashiCorp Vault) gespeichert wird, erschwert Angriffe zusätzlich, selbst wenn die komplette Passwort-Datenbank gestohlen wird, der Pepper aber nicht. Das ist kein Ersatz für starkes Hashing, sondern eine zusätzliche Schutzschicht, die vor allem bei besonders sensiblen Systemen wie Banking- oder Gesundheitsanwendungen sinnvoll ist. In Kombination mit Argon2id und einem sauber getrennt gespeicherten Pepper wird ein gestohlener Datenbank-Dump für Angreifer nahezu wertlos, solange der Pepper nicht ebenfalls kompromittiert wurde.

Ein weiterer oft übersehener Punkt: Rate-Limiting am Login-Endpunkt. Selbst der stärkste Hashing-Algorithmus schützt nicht vor Online-Angriffen, bei denen ein Angreifer direkt gegen das Login-Formular Passwörter durchprobiert, statt eine gestohlene Datenbank offline zu knacken. Tools wie Fail2ban oder eingebaute Rate-Limiting-Middleware in Frameworks wie Express oder Django reduzieren dieses Risiko unabhängig vom gewählten Hashing-Verfahren erheblich.

Alternative Verfahren: scrypt und PBKDF2 kurz eingeordnet

Neben bcrypt und Argon2id tauchen in Diskussionen häufig scrypt und PBKDF2 auf. scrypt war der erste weit verbreitete memory-hard-Algorithmus, vor Argon2, und wird etwa in einigen Kryptowährungs-Implementierungen genutzt. Es gilt als solide, aber weniger umfassend geprüft als Argon2. PBKDF2 ist der älteste der vier Ansätze, rein rechenintensiv ohne Speicherhärte, und wird hauptsächlich noch dort eingesetzt, wo regulatorische Vorgaben (etwa FIPS-Zertifizierung in bestimmten Behördenkontexten) explizit PBKDF2 verlangen. Für die meisten neuen Projekte ohne solche Zwangsvorgaben bleibt die Wahl zwischen bcrypt und Argon2id die relevante Entscheidung. Wichtig für die Einordnung: PBKDF2 ist keineswegs unsicher, solange die Iterationszahl hoch genug gewählt wird (aktuelle Empfehlungen liegen bei mehreren hunderttausend Iterationen für SHA-256-basierte Varianten), aber ohne Speicherhärte bleibt es gegen GPU-Angriffe strukturell schwächer als Argon2id. scrypt wiederum verlangt ebenfalls konfigurierbaren Speicher, hat sich aber wegen der etwas komplexeren Parametrisierung und der geringeren Verbreitung in Standardbibliotheken gegenüber Argon2 nicht durchgesetzt, obwohl es kryptografisch als solide gilt.

Passwort-Hashing ist nur ein Baustein der Kontosicherheit

So wichtig die Wahl des Hashing-Algorithmus ist, sie ersetzt keine weiteren Schutzmaßnahmen. Das BSI weist in seiner Bewertung gängiger 2FA-Verfahren darauf hin, dass Zwei-Faktor-Authentifizierung und Passwort-Hashing sich ergänzen, nicht ersetzen. Ein starker Argon2id-Hash schützt gegen Offline-Angriffe nach einem Datenbank-Diebstahl, verhindert aber nicht, dass ein Nutzer auf eine Phishing-Seite hereinfällt und sein Passwort im Klartext preisgibt. Wer 2026 ein Login-System plant, sollte Passwort-Hashing, Rate-Limiting, Zwei-Faktor-Authentifizierung und idealerweise Passkeys als sich ergänzende Schutzschichten behandeln, nicht als austauschbare Alternativen.

Argon2id, Passkeys und die Zukunft der Authentifizierung

Ein Blick nach vorn zeigt, dass Passwort-Hashing selbst mit Argon2id nur eine Übergangslösung sein könnte. Passkeys, basierend auf dem WebAuthn-Standard, verzichten komplett auf gemeinsame Geheimnisse zwischen Client und Server und nutzen stattdessen asymmetrische Kryptografie: Der private Schlüssel verlässt nie das Gerät der Nutzerin, der Server speichert nur einen öffentlichen Schlüssel, der bei einem Datenbank-Diebstahl für Angreifer wertlos ist. Damit entfällt das gesamte Offline-Cracking-Szenario, für das bcrypt und Argon2id überhaupt entwickelt wurden.

Trotzdem bleibt Passwort-Hashing 2026 hochrelevant, weil die vollständige Umstellung auf Passkeys bei den meisten Unternehmen Jahre dauert und viele Nutzer weiterhin klassische Passwörter als Fallback oder Zweitoption verwenden, etwa beim Gerätewechsel oder Kontowiederherstellung. Wer heute ein neues System aufsetzt, sollte deshalb beides parallel einplanen: Argon2id als solide Basis für den Passwort-Pfad, plus WebAuthn-Unterstützung für Nutzer, die direkt auf Passkeys umsteigen wollen. Die beiden Technologien schließen sich nicht aus, sie ergänzen sich während der langen Übergangsphase, in der klassische Passwörter aller Voraussicht nach noch mehrere Jahre parallel zu Passkeys existieren werden.

Das Urteil: Wann welcher Algorithmus?

Für neue Projekte ohne bestehende Nutzerbasis ist die Antwort 2026 eindeutig: Argon2id mit OWASP-Basisparametern (m=19456 KiB, t=2, p=1, oder höher bei verfügbaren Ressourcen). Der Sicherheitsgewinn gegenüber GPU- und ASIC-Angriffen ist in den Benchmarks aus drei unabhängigen Quellen konsistent belegt, bei vergleichbarer oder sogar besserer Hashzeit als bcrypt mit cost=12.

Für bestehende Systeme mit bcrypt gilt: Panik ist unangebracht, ein sofortiger Zwangs-Reset aller Passwörter unnötig. bcrypt mit Kostenfaktor 12 oder höher bleibt ein akzeptabler, wenn auch nicht optimaler Schutz. Der richtige Weg ist die schrittweise Rehash-on-Login-Migration, die neue Logins direkt auf Argon2id umstellt, ohne bestehende Nutzer zu zwingen, sich sofort neu zu registrieren. Wer 2026 noch ein komplett neues System auf reinem bcrypt aufbaut, ohne zumindest einen Migrationspfad zu Argon2id einzuplanen, verschenkt Sicherheit, die praktisch kostenlos zu haben ist.

Zusammengefasst in einem Satz: Argon2id gewinnt bei der reinen Widerstandsfähigkeit gegen moderne Hardware-Angriffe klar, bcrypt bleibt aus Kompatibilitäts- und Trägheitsgründen relevant, und die beste Strategie für die meisten Teams ist nicht Entweder-oder, sondern eine kontrollierte, schrittweise Migration von bcrypt zu Argon2id, begleitet von Rate-Limiting, Zwei-Faktor-Authentifizierung und, wo möglich, einem parallelen Angebot von Passkeys.

Häufig gestellte Fragen

Ist Argon2id sicherer als bcrypt?

Ja, gegen moderne Angriffsszenarien mit GPU-Clustern und spezialisierter Hardware bietet Argon2id durch seinen hohen Speicherbedarf einen klaren Vorteil. bcrypt ist dennoch nicht “unsicher”, es gilt weiterhin als solide, wenn der Kostenfaktor ausreichend hoch gewählt wird.

Muss ich bestehende bcrypt-Hashes sofort migrieren?

Nein. Ein sofortiger Massen-Reset ist weder nötig noch praktikabel, da die ursprünglichen Passwörter nicht vorliegen. Die gängige Praxis ist eine schrittweise Migration bei jedem erfolgreichen Login.

Welche Argon2id-Parameter sollte ich 2026 für ein neues Projekt verwenden?

Die OWASP-Basisempfehlung liegt bei m=19456 KiB, t=2, p=1. Systeme mit mehr verfügbarem Arbeitsspeicher können auf m=64 MiB, t=3, p=1 für zusätzliche Sicherheit gehen.

Warum begrenzt bcrypt Passwörter auf 72 Bytes?

Das liegt am zugrunde liegenden Blowfish-Schlüsselplan, der bcrypt intern verwendet und der auf diese Länge ausgelegt ist. Zeichen darüber hinaus werden stillschweigend ignoriert, was in seltenen Fällen zu unbeabsichtigt schwächeren effektiven Passwörtern führen kann.

Ist Argon2id für ressourcenarme Umgebungen wie IoT-Geräte geeignet?

Nur bedingt. Der hohe Speicherbedarf, der Argon2id sicher macht, kann auf Geräten mit wenig RAM zum Problem werden. Hier ist bcrypt oder eine Argon2id-Konfiguration mit stark reduzierten, aber sorgfältig geprüften Parametern eine praktikablere Wahl.

Reicht Passwort-Hashing allein für sichere Logins?

Nein. Passwort-Hashing schützt primär gegen Offline-Angriffe nach einem Datenbank-Diebstahl. Zwei-Faktor-Authentifizierung, Rate-Limiting gegen Brute-Force-Versuche am Login-Endpunkt und idealerweise Passkeys ergänzen diesen Schutz und sollten nicht weggelassen werden.

Kann ich bcrypt und Argon2id parallel im selben System einsetzen?

Ja, das ist sogar der übliche Weg während einer Migration. Ein zusätzliches Datenbankfeld markiert, welcher Algorithmus für welchen Hash verwendet wurde, sodass beide Verfahren so lange koexistieren können, bis die Migration abgeschlossen ist.

Was ist der Unterschied zwischen Argon2i, Argon2d und Argon2id?

Argon2d ist optimiert gegen GPU-Angriffe, aber anfälliger für Seitenkanalangriffe. Argon2i schützt besser gegen Seitenkanäle, ist aber schwächer gegen reine Rechenkraft. Argon2id kombiniert beide Ansätze und ist die in RFC 9106 empfohlene Variante für Passwort-Hashing.