bcrypt vs Argon2: So wählen Sie sichere Einstellungen für Passwort‑Hashing

Welches Problem Passworthashing löst

Passworthashing ermöglicht einem Backend, ein Passwort zu speichern, ohne das Passwort selbst zu speichern. Wenn sich jemand registriert, verarbeitet der Server das Passwort durch eine Einwegfunktion und speichert das Ergebnis (den Hash). Beim Login wird das eingegebene Passwort gehasht und das Ergebnis mit dem gespeicherten Wert verglichen.

Ein Hash ist keine Verschlüsselung. Es gibt keinen Weg, ihn zu entschlüsseln. Genau diese Einweg-Eigenschaft ist der Grund, warum Hashing für Passwörter verwendet wird.

Warum also nicht einen normalen schnellen Hash wie SHA-256 verwenden? Weil „schnell“ genau das ist, was Angreifer wollen. Wenn eine Datenbank gestohlen wird, raten Angreifer Passwörter nicht durch einmaliges Einloggen. Sie raten offline mit der gestohlenen Hash-Liste und drücken so viele Versuche wie ihre Hardware erlaubt. Mit GPUs können schnelle Hashes in enormem Maßstab getestet werden. Selbst mit einzigartigen Salts ist ein schneller Hash immer noch billig zu bruteforcen.

Das reale Versagensszenario: Eine kleine Web‑App verliert ihre Nutzertabelle in einem Leak. Der Angreifer bekommt E‑Mails und Passwort‑Hashes. Wurden diese Hashes mit einer schnellen Funktion erstellt, fallen gebräuchliche Passwörter und kleine Varianten schnell. Dann versucht der Angreifer dasselbe Passwort auf anderen Seiten (Credential Stuffing) oder nutzt es, um höher privilegierte Funktionen in Ihrer App zu erreichen.

Ein guter Passwort-Hash macht das Raten teuer. Das Ziel ist nicht „unknackbar“, sondern „zu langsam und zu teuer, um sich zu lohnen“.

Eine Passwort‑Hashing‑Konfiguration sollte sein:

• Einweg (verifizieren, nicht rückgängig machen)
• Pro Versuch langsam
• Teuer für parallele Hardware (insbesondere GPUs)
• Schnell genug, damit echte Logins normal wirken
• Anpassbar, damit Sie die Kosten im Laufe der Zeit erhöhen können

bcrypt und Argon2 in einer Minute

Wenn Sie bcrypt vs Argon2 vergleichen, entscheiden Sie, wie Sie das Erraten von Passwörtern nach einem Datenbankleck verlangsamen wollen.

bcrypt ist die ältere, weit verbreitete Option. Es ist so konzipiert, dass es CPU‑intensiv ist, und hat einen Hauptregler: den Kostenfaktor. Es ist auch „langweilig“ im guten Sinn: in vielen Bibliotheken verfügbar, einfach zu deployen und vorhersehbar.

Argon2 ist neuer und wurde als speicherintensiv (memory‑hard) entworfen. Es kann jeden Passwort‑Versuch dazu zwingen, eine nennenswerte Menge RAM zu verwenden, nicht nur CPU‑Zeit. Das ist wichtig, weil Angreifer häufig viele Versuche parallel auf GPUs oder spezialisierter Hardware laufen lassen. Speicher ist bei solch paralleler Skalierung teurer und schwerer zu erweitern.

Argon2 hat drei Varianten:

• Argon2i: legt Wert auf Widerstand gegen bestimmte Seitenkanalattacken
• Argon2d: legt Wert auf GPU‑Widerstand, mit anderen Seitenkanal‑Überlegungen
• Argon2id: eine praktische Mischung aus beidem und die gängige Default‑Wahl für Passwort‑Hashing

Wenn Ihr Stack Argon2id unterstützt und Sie den Speicher sicher einstellen können, ist es meist die beste moderne Default‑Wahl. Wenn Sie maximale Kompatibilität mit älteren Systemen benötigen, ist bcrypt bei ausreichendem Kostenfaktor nach wie vor eine solide Wahl.

Sicherheitsmerkmale, die am wichtigsten sind

Die Kernfrage ist einfach: Wenn ein Angreifer die Passwortdatenbank stiehlt, wie teuer ist es, Passwörter in großem Maßstab zu erraten?

Bei bcrypt steuern Sie die Kosten (Work Factor). Höhere Kosten bedeuten, dass jeder Versuch länger dauert. Das verlangsamt Angreifer, verlangsamt aber auch Ihre eigenen Login‑Checks, sodass man einen Punkt anstrebt, der für Angreifer schmerzhaft, für Nutzer aber noch akzeptabel ist.

Bei Argon2id können Sie zusätzlich zur Zeitkosten Speicher‑Härte hinzufügen. Jeder Versuch benötigt CPU‑Zeit und RAM, der in einem bestimmten Muster genutzt wird. GPUs sind bei reiner Rechenarbeit sehr schnell, verlieren aber viel von ihrem Vorteil, wenn jeder parallele Versuch erheblichen Speicher braucht.

Salts sind unverzichtbar. Ein einzigartiger, zufälliger Salt pro Passwort:

• verhindert, dass vorgefertigte Tabellen quer über die Datenbank wiederverwendet werden
• sorgt dafür, dass identische Passwörter nicht identische Hashes bei verschiedenen Nutzern erzeugen

Salts machen schwache Passwörter nicht stark. Sie schützen hauptsächlich nach einem Datenbankleck, indem sie Angreifer zwingen, pro Nutzer echte Arbeit zu leisten.

Stärken und Grenzen von bcrypt, die Sie kennen sollten

bcrypt wird immer noch weit verwendet, hauptsächlich, weil es überall einsetzbar ist. Es passt gut, wenn Sie breite Interoperabilität brauchen, Ihr Stack begrenzte Krypto‑Optionen hat oder Sie nur einen einfachen Tuning‑Regler wünschen.

Die größte Überraschung ist das 72‑Byte‑Limit. bcrypt verwendet nur die ersten 72 Bytes des Passworts und ignoriert den Rest. Das kann bei langen Passphrasen oder bei Passwortmanagern zu unerwartetem Verhalten führen.

Wenn Sie bcrypt wählen, machen Sie das Verhalten bei Passwortlänge deutlich. Entweder setzen Sie eine maximale Länge (in Bytes, nicht Zeichen) durch oder Sie behandeln lange Eingaben konsistent in allen Diensten. Wichtig ist, stille Trunkierung zu vermeiden, die das Passwort, wie der Nutzer es versteht, verändert.

bcrypt ist gegenüber moderner paralleler Knacker‑Hardware weniger resistent als speicherintensive Optionen. Seine Verteidigung ist immer noch gültig, beruht aber stark darauf, einen Kostenfaktor zu wählen, der jeden Versuch teuer macht.

Wenn Sie ein neues System bauen oder hohe Wertekonten (bezahlte Pläne, Admin‑Rollen) haben, ist es üblich, neue Hashes zu Argon2id zu migrieren und weiterhin bestehende bcrypt‑Hashes zu akzeptieren, bis sich Nutzer einloggen — ein meist risikoarmer Weg.

Stärken und Kompromisse von Argon2

Argon2 wurde für Passwort‑Hashing entwickelt. Argon2id ist die Variante, die die meisten Teams wählen, weil sie GPU‑Widerstand mit einem vernünftigen Schutz gegen Seitenkanal‑Probleme ausbalanciert.

Argon2id gibt Ihnen drei Parameter:

• Memory (m): wie viel RAM jeder Hash während der Ausführung verwendet
• Time/Iterations (t): wie viele Durchgänge über diesen Speicher gemacht werden
• Parallelism (p): wie viele Lanes genutzt werden (hilft auf Mehrkern‑CPUs)

Speicher ist der Hauptvorteil. Wenn jeder Versuch einen nennenswerten RAM‑Einsatz benötigt, können Angreifer nicht so viele Versuche parallel ausführen, ohne massiv in Speicher‑Kapazität und Bandbreite zu investieren.

Der Nachteil ist der operative Aufwand: Mehr Speicher pro Hash bedeutet weniger gleichzeitige Logins, bevor Ihre Server an ihre Grenzen geraten. Wenn Sie den Speicher zu hoch setzen, können Login‑Spitzen zu Warteschlangen, Timeouts oder sogar Out‑of‑Memory‑Fehlern führen. Denken Sie auch an Missbrauch: Viele gleichzeitige Login‑Versuche können eine Ressourcenproblematik werden, wenn Sie die Arbeit nicht begrenzen.

Um Argon2id sicher und nutzbar zu halten, behandeln Sie es wie ein Performance‑Feature:

• messen Sie auf produktsimilarer Hardware
• begrenzen Sie gleichzeitige Hash‑Arbeit (Worker‑Caps, Queues)
• setzen Sie Ratenbegrenzungen für Logins und sperren Sie wiederholte Fehlschläge
• halten Sie Einstellungen konsistent über Dienste hinweg, damit ein schwacher Endpunkt nicht zum Ziel wird

Performance‑Kosten in echten Web‑Backends

Beim Passworthashing ist „schneller ist besser“ meistens das falsche Ziel. Sie wollen jeden Versuch für Angreifer teuer machen, während Logins für echte Nutzer trotzdem flink bleiben.

Eine praktische Methode ist ein Zeitbudget pro Verifikation auf Ihrer tatsächlichen Produktionshardware. Viele Teams zielen auf etwa 100 bis 300 ms pro Hash‑Check, aber die richtige Zahl hängt von Traffic und Servern ab. Der Unterschied zwischen bcrypt und Argon2 ist, wofür Sie bezahlen: bcrypt ist hauptsächlich CPU‑Zeit, während Argon2 auch Speicher reservieren kann.

Wählen Sie eine Zielzeit und messen Sie dann

Wählen Sie eine Ziel‑Hash‑Zeit und testen Sie unter Bedingungen, die der Produktion ähneln. Messen Sie sowohl Registrierung/Passwortänderung als auch Login‑Verifikation, behandeln Sie aber Login als den heißen Pfad.

Ein leichtes Messprogramm:

• testen Sie 1, 10 und 50 gleichzeitige Login‑Checks und protokollieren Sie p50 und p95 Latenz
• wiederholen Sie Läufe, um Rauschen durch Caching und CPU‑Boosting zu reduzieren
• messen Sie den Datenbank‑Aufruf separat, damit Sie wissen, was das Hashing wirklich kostet
• testen Sie mit demselben Container‑ und CPU‑Limit wie in der Produktion

Spitzen sind wichtiger als Durchschnitte

Die meisten Systeme versagen während Spitzen. Wenn eine Marketing‑Mail eine Welle von Nutzern zur Login‑Seite schickt, entscheiden Ihre Hash‑Einstellungen, ob das System responsiv bleibt.

Wenn eine Verifikation 250 ms dauert und Ihr Server 40 gleichzeitig verarbeiten kann, bevor es zu Warteschlangen kommt, kann eine Welle von 500 Login‑Versuchen in mehrsekündige Wartezeiten verwandelt werden. In diesem Fall kann eine kleine Reduzierung der Kosten plus starke Ratenbegrenzungen die reale Sicherheit mehr verbessern, als die Parameter so hoch zu treiben, dass der Login‑Endpunkt fragil wird.

Interaktive Logins vorhersehbar halten

Nicht jede Passwort‑Operation hat dieselbe Dringlichkeit. Halten Sie die Kosten für interaktive Logins stabil und verschieben Sie schwere Arbeit aus dem kritischen Pfad. Ein gängiges Muster ist Rehash‑on‑Login (ein Nutzer wird nach einem erfolgreichen Login mit stärkeren Einstellungen neu gehasht) oder Hintergrundjobs für Migrationen und Importe.

Schritt‑für‑Schritt: Wie man Parameter wählt

Das Tuning von Parametern bedeutet, die Kosten pro Erraten zu erhöhen, ohne Anmeldungen langsam zu machen oder Server zu destabilisieren.

1. Wählen Sie einen Algorithmus, den Ihr Stack gut unterstützt. Wenn Argon2id verfügbar und gut unterstützt ist, ist es meist die Default‑Wahl. Für maximale Kompatibilität ist bcrypt in Ordnung.

2. Setzen Sie eine Zielzeit pro Hash auf produktsimilarer Hardware. Wählen Sie etwas, das Logins auch bei Spitzen glatt hält.

3. Tunen Sie, um diese Zeit zu erreichen. Bei bcrypt passen Sie den Kostenfaktor an. Bei Argon2id balancieren Sie Speicher, Iterationen und Parallelismus. Speicher ist der Hebel, der die Ökonomie für Angreifer am stärksten verändert.

4. Speichern Sie Algorithmus und Einstellungen mit dem Hash. Die meisten Standard‑Hash‑Formate betten diese Details ein. Stellen Sie außerdem sicher, dass Ihr Datenbankfeld lang genug ist, damit Hashes nicht abgeschnitten werden.

5. Planen Sie Upgrades mit Rehash‑on‑Login. Wenn sich ein Nutzer einloggt und sein gespeicherter Hash schwächere Einstellungen hat als Ihre aktuelle Policy, rehashen und ersetzen Sie ihn.

Ein praktischer Startpunkt

Wenn Sie vor dem Messen eine Basis brauchen, starten Sie konservativ und passen Sie nach Timing an.

• Bei bcrypt beginnen viele Teams bei Kostenfaktor 12 und passen basierend auf realen Messungen an.
• Bei Argon2id ist eine gebräuchliche Ausgangskonfiguration Speicher im Bereich von einigen zehn bis ein paar hundert MB, Zeitkosten 2–4 und Parallelismus 1–2.

Behandeln Sie das als Ausgangspunkt, nicht als starre Regel. Die richtigen Einstellungen passen zu Ihrem Traffic, Ihrer Hardware und Ihren Spitzenlasten.

Häufige Fehler, die die Passwortspeicherung schwächen

Die meisten Fehler entstehen durch Konfigurationslücken, nicht durch einen defekten Algorithmus.

Salt‑Fehler sind entscheidend. Jedes Passwort braucht seinen eigenen, einzigartigen Salt, der mit dem Hash gespeichert wird. Wiederverwendung von Salts oder ein globaler Salt für alle Nutzer erleichtert Angreifern die Wiederverwendung von Arbeit und den Vergleich von Accounts.

Vernachlässigte Kosten sind ein weiterer Punkt. Teams liefern oft mit niedrigen Kosten aus, weil das Login schneller wirkt, und überprüfen das nie wieder. Hardware verbessert sich, Angreifer skalieren auf, und Ihre ehemals akzeptablen Einstellungen werden billig.

Argon2‑Über‑Tuning kommt auch vor. Sehr hohe Speicherwerte sehen auf dem Papier gut aus, führen aber zu langsamen Logins, Backlogs oder Out‑of‑Memory‑Fehlern bei realen Spitzen.

Passwortlängen‑Handhabung ist wichtig, besonders wegen bcryp ts 72‑Byte‑Verhalten. Erlauben Sie lange Passwörter, aber trunkieren Sie nicht stillschweigend — das verwirrt Nutzer und reduziert Sicherheit.

Ein paar praktische Gewohnheiten verhindern das meiste:

• benutzen Sie für jedes Passwort einen einzigartigen Salt (lassen Sie die Bibliothek ihn generieren)
• führen Sie Lasttests durch und überprüfen Sie Einstellungen regelmäßig
• stimmen Sie Argon2‑Speicher für Spitzenlasten ab, nicht nur für Einzeltests
• machen Sie Passwortlängenlimits explizit und konsistent
• setzen Sie Nebenläufigkeitsgrenzen und Monitoring um den Login‑Endpunkt

Kurze Checkliste für eine sicherere Konfiguration

Behalten Sie diese Liste beim Ausliefern und bei Infrastrukturänderungen griffbereit:

• Einzigartiger Salt pro Passwort, zufällig generiert und mit dem Hash gespeichert
• Hashing‑Kosten, die Spitzenverkehr überstehen, verifiziert mit Lasttests auf produktsimilarer Hardware
• Parameter mit dem Hash gespeichert, damit Sie alte Accounts verifizieren und später die Kosten erhöhen können
• Online‑Angriffssteuerung, inklusive Ratenbegrenzungen und kurzer Sperren bei wiederholten Fehlschlägen
• Ein Upgrade‑Pfad, normalerweise Rehash‑on‑Login

Eine einfache Sanity‑Prüfung: Führen Sie in Staging einen Test mit einem Login‑Burst (erfolgreich und fehlgeschlagen) aus und beobachten Sie End‑to‑End‑Latenz sowie CPU‑ und RAM‑Nutzung. Wenn der Login‑Pfad Probleme macht, passen Sie Kosten und Ratenbegrenzungen an. Schneiden Sie nicht an Essentials wie Salts, um das zu „reparieren“.

Ein realistisches Beispiel: Tuning für eine kleine Web‑App

Stellen Sie sich eine kleine SaaS‑App mit ein paar tausend Nutzern vor. Meist ist der Betrieb ruhig, aber Sie sehen kurze Login‑Spitzen nach einem Newsletter oder zu Beginn des Arbeitstages. Hier wird die Wahl zur Kapazitätsplanung.

Sie wählen Argon2id, um die Kosten des Offline‑Crackings zu erhöhen. Legen Sie eine Ziel‑Verifikationszeit auf Ihrer echten Server‑Hardware fest (z. B. 100–250 ms) und passen Sie Parameter so an, dass Sie diese Zeit treffen, während Sie den RAM im Auge behalten, denn Speicher‑Einstellungen können begrenzen, wie viele Logins gleichzeitig möglich sind.

Eine praktische Tuning‑Schleife sieht so aus:

• beginnen Sie mit moderaten Iterationen und Parallelismus
• erhöhen Sie den Speicher, bis die Nebenläufigkeit unbequem wird
• passen Sie die Iterationen an, um die Zeitkosten feinzujustieren
• testen Sie erneut mit simulierten Spitzen, nicht nur mit Einzelanfragen

Haben Sie bereits ältere Hashes mit schwächeren Einstellungen, verifizieren Sie diese weiter, aber upgraden Sie stillschweigend. Nach erfolgreichem Login rehashen Sie mit aktuellen Einstellungen und speichern den neuen Wert. Mit der Zeit bewegen sich aktive Nutzer so zu stärkeren Hashes, ohne erzwungene Resets.

Nach dem Release überwachen Sie das Login wie jeden anderen kritischen Endpunkt: tail‑Latenz (p95/p99), CPU und RAM während Spitzen, Anstiege bei Fehlanmeldungen und wie schnell alte Hashes ersetzt werden.

Nächste Schritte: Sicher ausliefern und weiter verbessern

Schreiben Sie Ihre Policy auf und behandeln Sie sie als lebendige Einstellung. Zum Beispiel: „Argon2id mit X MB Speicher, Y Iterationen, Z Parallelismus“ oder „bcrypt Kostenfaktor N“, plus Datum der Auswahl und Review‑Intervall (alle 6–12 Monate ist ein guter Start).

Halten Sie einen Upgrade‑Pfad bereit, damit Sie nicht an alten Hashes hängen bleiben. Rehash‑on‑Login ist einfach und funktioniert in den meisten Systemen gut.

Ein starker Hash ersetzt nicht die Online‑Abuse‑Kontrollen. Ratenbegrenzungen, Sperren und sorgfältige Passwort‑Reset‑Flows sind ebenso wichtig für reale Sicherheit.

Wenn Sie Ihr Backend mit einer No‑Code‑Plattform wie AppMaster bauen, prüfen Sie, ob Ihr Authentifizierungsmodul standardmäßig starke Passwort‑Hashes nutzt und ob die Hashing‑Kosten auf derselben Infrastruktur abgestimmt sind, auf der Sie deployen wollen. Dieses kleine Voraus‑Testen macht oft den Unterschied zwischen „sicher und flüssig“ und „sicher, aber unter Last unbrauchbar“.