Argon2 Generator & Verifier
Passwort-Hashes nach Argon2 erzeugen und prüfen – in allen drei Varianten – und dabei sehen, was jeder einzelne Parameter im Hash bedeutet. Alles läuft lokal in deinem Browser.
Empfohlene Standardvariante – Mischung aus Argon2i und Argon2d.
Ergebnis
Aufbau des Hashes
VarianteVersionSpeicherDurchläufeParallelitätSaltDigest| Bestandteil | Wert | Bedeutung |
|---|---|---|
| Variante | | |
| Version | | |
| Speicher | | |
| Durchläufe | | |
| Parallelität | | |
| Salt | | |
| Digest | |
Alles läuft lokal in deinem Browser – weder Passwort noch Hash werden hochgeladen.
Wie ein Argon2-Hash aufgebaut ist
Argon2 schreibt seine Hashes im PHC-String-Format – benannt nach der Password Hashing Competition, die Argon2 2015 gewonnen hat. Anders als bei bcrypt ist die Länge nicht fest, weil Salt und Digest frei dimensioniert werden können. Der Aufbau ist aber ebenso streng:
$argon2id$v=19$m=65536,t=3,p=4$c29tZXNhbHQxMjM0NTY$RdescudvJCsgt3ub+b+dWRWJTmaaJObGtL8kZ1kZ2xY
└────────┘└───┘└──────┘└──┘└──┘└──────────────────┘└─────────────────────────────────────────┘
│ │ │ │ │ │ │
│ │ │ │ │ │ └── Digest, Base64 ohne Padding
│ │ │ │ │ └── Salt, Base64 ohne Padding
│ │ │ │ └── Parallelität (Lanes)
│ │ │ └── Durchläufe
│ │ └── Speicher: 65.536 KiB = 64 MiB
│ └── Version 1.3
└── VarianteAuffällig ist das Base64 am Ende: Es steht ohne „=“-Padding da – so schreibt es die PHC-Spezifikation vor. Wer einen Argon2-Hash selbst zerlegt, muss das Padding vor dem Dekodieren wieder ergänzen, sonst scheitert jede Standard-Base64-Funktion.
Die drei Varianten
Argon2id ist die Hybridvariante und laut RFC 9106 die erste Wahl für Passwörter. Ihr erster halber Durchlauf arbeitet speicherzugriffs-unabhängig, der Rest datenabhängig – sie kombiniert damit die Stärken der beiden anderen. Wenn du keinen zwingenden Grund für etwas anderes hast, nimm diese.
Argon2i greift in einem Muster auf den Speicher zu, das nicht vom Passwort abhängt. Damit lernt selbst ein Angreifer nichts über das Passwort, der das Zugriffsmuster beobachten kann – etwa über einen Seitenkanal auf geteilter Hardware. Der Preis dafür: gegen Angreifer mit sehr viel paralleler Rechenleistung ist Argon2i schwächer als Argon2d.
Argon2d greift datenabhängig zu und wehrt Angriffe mit Grafikkarten und Spezialchips am besten ab, ist dafür aber anfällig für Seitenkanal-Angriffe. Es ist für Anwendungen ohne diese Gefahr gedacht, etwa im Umfeld von Kryptowährungen – für Passwörter in einer Webanwendung ist es die falsche Wahl.
Was m, t und p bedeuten
m (Speicher) ist der Parameter, der Argon2 von älteren Verfahren abhebt. Er gibt an, wie viel Arbeitsspeicher in KiB eine einzelne Berechnung belegt. Genau das bremst Angreifer aus: Wer das Durchprobieren auf tausende Kerne einer Grafikkarte verteilen will, braucht diesen Speicher pro gleichzeitigem Versuch. Bei bcrypt gibt es dafür kein Gegenstück – deshalb gilt Argon2 als der modernere Ansatz.
t (Durchläufe) legt fest, wie oft über diesen Speicher gelaufen wird. Das ist ein linearer Faktor: doppelt so viele Durchläufe, doppelte Rechenzeit. Die Empfehlung lautet, zuerst den Speicher so hoch wie vertretbar zu setzen und erst danach an t zu drehen.
p (Parallelität) ist die Zahl der Spuren, auf die die Arbeit verteilt wird. Wichtig: Der Wert gehört zum Hash. Beim Prüfen muss dieselbe Zahl verwendet werden, sonst kommt ein anderes Ergebnis heraus – unabhängig davon, wie viele Kerne die prüfende Maschine gerade hat.
Welche Werte sind sinnvoll?
RFC 9106 nennt zwei Profile: 2 GiB Speicher mit t=1 und p=4, oder – wenn so viel Speicher nicht verfügbar ist – 64 MiB mit t=3 und p=4. Das OWASP Password Storage Cheat Sheet nennt als praxisnahe Untergrenze 19 MiB mit t=2 und p=1. Alle drei findest du oben als Voreinstellung; das 2-GiB-Profil ist hier nicht dabei, weil der Browser so viel Speicher einer WebAssembly-Berechnung nicht am Stück zuteilt.
Häufige Fragen
Argon2 oder bcrypt?
Für neue Systeme gilt Argon2id als erste Wahl, weil es zusätzlich zur Rechenzeit auch den Speicherbedarf hochschraubt und damit Spezialhardware ausbremst. bcrypt ist deswegen nicht kaputt: Es ist seit 1999 im Einsatz und gründlich untersucht. Wer bereits bcrypt nutzt, hat keinen akuten Handlungsdruck. Für bcrypt gibt es ein eigenes Tool auf bcrypt.rellit.de.
Warum steht bei manchen Hashes kein „v=“?
Solche Hashes stammen aus der Zeit vor 2016 und sind implizit Version 1.0. Diese Version hat eine bekannte Schwäche und wurde durch 1.3 (v=19) abgelöst. Findest du solche Hashes in einer Datenbank, sollten sie beim nächsten erfolgreichen Login neu berechnet werden.
Kann man einen Argon2-Hash zurückrechnen?
Nein. Argon2 ist eine Einwegfunktion, keine Verschlüsselung. Prüfen heißt: das eingegebene Passwort mit exakt denselben Parametern und demselben Salt erneut durchrechnen und vergleichen. Deshalb stehen alle Parameter offen im Hash – ohne sie wäre eine spätere Prüfung unmöglich.
Warum dauert die Berechnung hier länger als auf meinem Server?
Weil sie in WebAssembly in einem einzelnen Browser-Thread läuft. Der Parameter p verteilt die Arbeit zwar rechnerisch auf mehrere Spuren, aber nicht auf mehrere Kerne. Nimm die angezeigte Zeit also als groben Anhaltspunkt, nicht als Messwert für deine Produktivumgebung.
Werden meine Eingaben hochgeladen?
Nein. Das Rechnen erledigt ein WebAssembly-Modul direkt in deinem Browser. Es gibt keinen Server, der dein Passwort oder deinen Hash zu sehen bekäme. Trotzdem gilt: Echte Produktiv-Passwörter gehören grundsätzlich in kein Web-Tool, auch nicht in dieses.