# Hash, Salt, bcrypt und Argon2: Was eine ordentlich gebaute Website mit deinem Passwort macht > Eine ordentlich gebaute Website kennt dein Passwort nicht: Sie speichert einen Fingerabdruck. Und die Funktion, die diesen Fingerabdruck berechnet, muss absichtlich langsam sein — denn das ist die einzige Verteidigung, bei der Verteidiger und Angreifer exakt dasselbe Rennen laufen. 2026-03-26 · David Carrero · password.es Original: https://password.es/de/blog/hash-salt-bcrypt-argon2-passwoerter/ --- Eine ordentlich gebaute Website kennt dein Passwort nicht. Nicht, weil sie nicht wollte: Sie kann es nicht. Das klingt nach einem Taschenspielertrick, denn jedes Mal, wenn du es eintippst, lässt dich das System durch — und um dich durchzulassen, muss es irgendetwas prüfen. Aber prüfen ist nicht wissen. Der Server speichert einen **Fingerabdruck**, der aus deinem Passwort berechnet wurde; wenn du es eingibst, berechnet er den Fingerabdruck erneut und vergleicht. Stimmen beide überein, bitte sehr. **An keiner Stelle muss das Passwort selbst irgendwo stehen.** Daraus ergibt sich das deutlichste Signal, an dem man einen seriösen Dienst von einem unseriösen unterscheidet: Wenn sie dir das vergessene Passwort per E-Mail zuschicken, hatten sie es gespeichert. Und was gespeichert ist, landet früher oder später bei jemand anderem. ## 1979: die Idee, sie nicht zu speichern — und die, es langsam zu tun 1979 veröffentlichten **Robert Morris und Ken Thompson** in den *Communications of the ACM* den Aufsatz „Password Security: A Case History" und berichteten darin, was sie in Unix gebaut hatten. Es ist ein Erfahrungsbericht, und in ihm werden zwei Ideen festgeschrieben, die wir heute für selbstverständlich halten. Die erste haben sie nicht erfunden — den Hash statt des Passworts zu speichern, machte man schon vorher —, aber sie haben sie besser erklärt als alle anderen: **nicht das Passwort speichern, sondern seinen Hash**. Eine Funktion, die dein Passwort in einen willkürlich aussehenden Wert verwandelt und die sich nicht rückwärts gehen lässt: Vom Hash kommt man nicht zum Passwort zurück. Die zweite ist tatsächlich ihre: **das Salt**. Ein für jeden Nutzer anderer Zufallswert, der vor der Berechnung des Hashs unter das Passwort gemischt wird. Ohne Salt haben zwei Personen mit demselben Passwort denselben Hash — die gestohlene Datei wird zum Suchspiel nach Dopplern — und, schlimmer noch: Jemand kann einmalig eine riesige Tabelle vorberechnen und sie gegen sämtliche Datenbanken der Welt einsetzen. **Das Salt macht dein Passwort nicht schwerer zu erraten: Es sorgt dafür, dass das Erraten niemandem sonst etwas nützt.** Aber in demselben Aufsatz steckt eine dritte Idee, die viel seltener zitiert wird — und genau um die geht es hier: Sie machten die Funktion **absichtlich langsam**. Nicht aus Nachlässigkeit. Mit Vorsatz. Ein Passwort zu verschlüsseln kostete weit mehr, als technisch nötig gewesen wäre, denn wer sich einmal pro Morgen anmeldet, merkt davon nichts — und wer Millionen Kandidaten durchprobiert, sehr wohl. Da steht die ganze Sache in einem Satz von vor fast fünfzig Jahren. ## Warum Langsamkeit die einzig ehrliche Verteidigung ist Fast alle Verteidigungen in der Informatik sind asymmetrisch: Sie kosten den Verteidiger wenig und den Angreifer viel. Verschlüsseln ist billig; ohne Schlüssel entschlüsseln ist aussichtslos. Der Verteidiger spielt mit einem strukturellen Vorsprung. Beim Speichern von Passwörtern nicht. **Hier führen Verteidiger und Angreifer exakt dieselbe Funktion aus.** Du berechnest den Hash, um zu prüfen, ob du richtig liegst; er berechnet ihn, um zu prüfen, ob er richtig liegt. Es ist das einzige Rennen der Sicherheit, bei dem beide mit denselben Beinen laufen. Wenn du nicht schneller laufen kannst als dein Gegner, bleibt nur ein Zug: **die Bahn für beide teurer machen**. Du zahlst diesen Preis einmal pro Anmeldung. Er einmal pro Versuch. Da er um Größenordnungen mehr Versuche braucht als du, trifft euch dieselbe Rechnung völlig unvergleichbar. Genau das leistet ein Passwort-Hash. Deshalb sind schnelle und für anderes hervorragende Funktionen — SHA-256 etwa — hier eine miserable Wahl. Sie sind schnell. Schnell ist exakt das, was wir nicht wollen. ## 1999: bcrypt, und die Kosten als verstellbares Teil Das Problem einer langsamen Funktion ist, dass die Hardware nicht stehen bleibt. Was 1979 langsam war, ist später augenblicklich. Eine Verteidigung, die auf die Rechner eines Jahrzehnts geeicht ist, altert von allein, ohne dass jemand sie anfasst. 1999 stellten **Niels Provos und David Mazières** auf der USENIX Annual Technical Conference **bcrypt** vor, mit einem Titel, der schon alles sagt: *A Future-Adaptable Password Scheme*. Die Idee: Die Kosten sollen **nicht in der Funktion stecken, sondern in einem Parameter**. bcrypt trägt einen Kostenfaktor, den du festlegst und der neben dem Hash gespeichert wird. Wird die Hardware sehr viel schneller, drehst du die Zahl hoch, und neue Passwörter kosten wieder, was sie kosten sollen — ohne den Algorithmus zu wechseln. **Ein Entwurf, der sein eigenes Veralten einkalkuliert und sich darauf vorbereitet.** Es gibt verschwindend wenig Software, die das tut. ## 2009: scrypt, und die Entdeckung, dass Zeit nicht reicht bcrypt verteuert die Rechenzeit, und das funktionierte. Bis der Angreifer aufhörte, denselben Maschinentyp zu benutzen wie der Verteidiger. Ein Server hat ein paar wenige schnelle Allzweckkerne. Eine GPU hat eine Unmenge kleiner Kerne, die dasselbe parallel tun, und ein ASIC geht noch weiter: Silizium, gefertigt, um eine einzige Operation auszuführen. Wenn deine Verteidigung darin besteht, dass „diese Operation X kostet", kann jemand Hardware bauen, die viele X gleichzeitig erledigt. Der Verteidiger sitzt weiter an seinem Server. 2009 stellte **Colin Percival** **scrypt** mit einem anderen Argument vor: *Stronger Key Derivation via Sequential Memory-Hard Functions*. Wenn die Kosten nur im Rechnen liegen, lässt sich das parallelisieren. Aber **Speicher gibt es nicht geschenkt**. Zwingt man die Funktion, viel RAM zu benutzen und ihn so zu durchlaufen, dass man sich nicht daran vorbeimogeln kann, dann kann der Angreifer plötzlich keine Kerne mehr vervielfachen: Jeder Kern bräuchte seinen eigenen Speicher. Und die Kerne einer GPU haben viel Rechenleistung und sehr wenig RAM pro Stück. **Percival verteuerte nicht die Operation. Er verteuerte die Hardware, die nötig ist, um sie massenhaft zu wiederholen.** Das ist ein Ebenenwechsel: Angegriffen wird das Budget des Angreifers, nicht seine Uhr. ## 2015: Argon2, und das Ende der Debatte Dass es mehrere vernünftige Optionen gab, half niemandem bei der Wahl. Also tat die Kryptografie-Gemeinde, was sie üblicherweise tut, wenn sie eine Sache beenden will: einen öffentlichen Wettbewerb. Die **Password Hashing Competition** nahm Kandidaten entgegen, unterzog sie jahrelang offener Analyse und rief **2015** **Argon2** zum Sieger aus. Argon2 erbt beide Lektionen: Kosten in Zeit und Kosten in Speicher, beide getrennt einstellbar, dazu die Zahl der Threads. Keine Magie. Es ist die geordnete Synthese aus 1979, 1999 und 2009, geprüft von Leuten, deren Job darin bestand, sie zu brechen. ## Was das für dich bedeutet Fast nichts davon liegt in deiner Hand, und das gehört gesagt: **Den Hash wählt die Website, nicht du**. Du kannst das beste Passwort der Welt haben und sie legen es im Klartext in einer Excel-Tabelle ab. Aber die andere Seite der Gleichung hängt sehr wohl von dir ab. Dieses ganze Gebäude — das Salt, die Kosten, der Speicher — dient dazu, **jeden einzelnen Versuch** des Angreifers zu verteuern. Wie viele Versuche er braucht, entscheidet dein Passwort. Steht es in einem Wörterbuch, rettet dich keine langsame Funktion: Es fällt unter den ersten. Ist es lang und ähnelt es nichts, wird dieser Preis pro Versuch mit einer Zahl von Versuchen multipliziert, die in die verfügbare Zeit nicht hineinpasst. Deshalb misst unser [Generator](/de/) **Entropie-Bits** und keine Prozente, und deshalb sucht der [Passwort-Checker](/de/passwort-checker/) dein Passwort erst in Wörterbüchern, bevor er Sonderzeichen zählt. **Sie setzen den Preis pro Versuch; du setzt die Zahl der Versuche.** Keine der beiden Hälften funktioniert ohne die andere. Und ja: Es ist immer noch dieselbe Frage wie eh und je. Nur dass auf der anderen Seite jetzt jemand versucht, sie viele Male pro Sekunde zu beantworten — und wir seit 1979 daran arbeiten, dass ihn jedes einzelne dieser Male Geld kostet. --- *Quellen: R. Morris und K. Thompson, „Password Security: A Case History", Communications of the ACM, 1979 · N. Provos und D. Mazières, „A Future-Adaptable Password Scheme", USENIX Annual Technical Conference, 1999 (bcrypt) · C. Percival, „Stronger Key Derivation via Sequential Memory-Hard Functions", 2009 (scrypt) · Password Hashing Competition, Sieger Argon2, 2015.*