Wenn eine Webseite dir sagt, dein Passwort brauche drei Millionen Jahre, bis es geknackt sei, dann lässt sie den wichtigsten Teil des Satzes weg. Die richtige Frage lautet nicht, wie lange es dauert. Sie lautet: wie lange wogegen.
Und das Wogegen entscheidest nicht du. Entschieden hat es ein Entwickler jenes Shops, in dem du 2019 ein Paar Sneaker gekauft hast — in dem Moment, als er festlegte, wie dein Passwort in seiner Datenbank landet. Du hast an beiden Stellen dieselbe zwanzigstellige Zeichenkette getippt. An der einen hält sie Jahrhunderte, an der anderen fällt sie vor der Mittagspause.
Die Zahl, die in der Gleichung fehlt
Ein Brute-Force-Angriff ist banale Rechnerei: Anzahl der Kandidaten, die man durchprobieren muss, geteilt durch die Kandidaten, die man pro Sekunde durchprobieren kann. Der erste Faktor hängt an deinem Passwort — Länge, Alphabet, ob es im Wörterbuch steht oder nicht. Der zweite hat mit dir schlichtweg gar nichts zu tun.
Der zweite Faktor hängt an zwei Dingen: an der Hardware des Angreifers und vor allem an der Funktion, mit der die Seite dein Passwort in den Buchstabensalat verwandelt hat, der in ihrer Benutzertabelle steht. Diese Funktion heißt Hash, und nicht alle kosten gleich viel Rechenzeit.
MD5 und SHA-1 wurden auf Tempo gebaut. Das ist erst mal eine Tugend: Es sind Allzweck-Hashfunktionen, gedacht zum Zusammenfassen von Nachrichten und zum Prüfen von Integrität, und da will man ein Gigabyte durchjagen, ohne zwischendurch Kaffee holen zu können. Wenn jemand sie zum Speichern von Passwörtern einsetzt, wird aus der Tugend das Problem. Eine Funktion, die du millionenfach pro Sekunde berechnen kannst, ist eine Funktion, die auch der Angreifer millionenfach pro Sekunde berechnen kann — und der hat Grafikkarten und das ganze Wochenende.
bcrypt und Argon2 wurden mit dem gegenteiligen Ziel entworfen. Sie sind absichtlich langsam, und — das ist der elegante Teil — die Langsamkeit lässt sich regeln. Niels Provos und David Mazières stellten bcrypt 1999 unter einem Titel vor, der alles sagt: A Future-Adaptable Password Scheme. Die Idee war, dass die Funktion über die Jahre teurer werden kann, in dem Tempo, in dem die Hardware billiger wird. Argon2, Sieger der Password Hashing Competition 2015, drehte noch eine Schraube weiter: Es kostet nicht nur Zeit, es kostet Speicher — und davon haben GPUs deutlich weniger großzügig etwas übrig.
Zwischen einem schnellen und einem gut konfigurierten langsamen Hash liegt kein Unterschied in Prozent. Da liegen Größenordnungen. Viele.
Die Benchmarks gibt es, und sie sind öffentlich
Nichts davon ist Spekulation. Hashcat, das Werkzeug, mit dem die halbe Welt Passwörter knackt — die Guten eingeschlossen —, bringt einen Benchmark-Modus mit, den jeder auf der eigenen Maschine starten kann und der Algorithmus für Algorithmus misst, wie oft pro Sekunde sich jeder berechnen lässt. Die Community veröffentlicht diese Tabellen bei jeder neuen GPU-Generation.
Das Interessante an den Tabellen ist keine einzelne Zahl — die veraltet ohnehin mit jeder Hardware-Generation —, sondern der Abstand zwischen den Zeilen. Man sortiert nach Geschwindigkeit und sieht MD5 ganz oben, auf einem eigenen Planeten. Man scrollt und scrollt, und am Tabellenende stehen bcrypt und Argon2, mit Zahlen, die nicht die geringste Ähnlichkeit mehr haben. Es ist dasselbe Passwort. Es ist dieselbe GPU. Verändert hat sich nur, wie die Seite es zu speichern beschloss.
Deshalb ist „3 Millionen Jahre“ ohne Angabe des Hashs Marketing und keine Messung. Das ist, als würde man werben, dass dein Auto sechs Stunden bis zur Ankunft braucht, ohne das Ziel zu nennen.
Offline und online: zwei Welten, die sich nicht berühren
Es gibt eine zweite Unterscheidung, die fast niemand erklärt und die das Ergebnis genauso brutal verschiebt.
Bei einem Online-Angriff probiert der Angreifer Passwörter gegen das Anmeldeformular, so wie ein Benutzer es täte. Das Tempo gibt nicht seine Hardware vor, sondern der Server. Da kann es ein Versuchslimit geben, eine zeitweilige Sperre, ein Captcha, eine Verzögerung zwischen Anfragen, Alarme, wenn tausend Fehlversuche von derselben Adresse kommen. Gegen eine halbwegs anständig verteidigte Seite ist ein Online-Angriff langsam, laut und ziemlich dämlich. Die Rechnung geht für den Angreifer so schlecht auf, dass reine Brute Force kaum noch versucht wird: Man probiert die immergleichen vier Passwörter gegen Millionen Konten durch, und das ist ein anderes Spiel.
Bei einem Offline-Angriff hat der Angreifer den Datenbank-Dump bereits. Er nimmt ihn mit nach Hause. Dort gibt es keinen Server, kein Versuchslimit, niemanden, der zusieht: Es gibt seine Grafikkarten und seine Stromrechnung. Er kann monatelang probieren, ohne dass es irgendwer mitbekommt, und er merkt ganz allein, wann er richtig geraten hat — durch Hashvergleich. Hier entscheidet der Hash alles, denn der Hash ist buchstäblich das Einzige, was ihn bremst.
Und man sollte bei den Wahrscheinlichkeiten ehrlich bleiben: Das Offline-Szenario ist nichts Exotisches. Es ist das, was jedes Mal passiert, wenn eine Datenbank durchsickert. Als LinkedIn 2012 seine verlor, zeigte die Analyse des geleakten Dumps, dass die Passwörter mit SHA-1 ohne Salt gespeichert waren: ein schneller Hash, und ohne die Zutat, die das Vorberechnen von Tabellen verhindert. Dass so viele davon so schnell fielen, lag nicht nur daran, dass die Benutzer schlecht gewählt hatten. Es lag vor allem an einer Ingenieursentscheidung, die kein einziger Benutzer je zu Gesicht bekam.
Was wir hier machen, und warum wir es dazusagen
Unser Passwort-Checker rechnet mit 10¹² Versuchen pro Sekunde, offline, gegen einen schnellen Hash. Das steht auf der Seite selbst, direkt unter dem Ergebnis, und nicht aus dekorativer Transparenz: Ohne diese Angabe bedeutet die Zeit, die dort steht, überhaupt nichts.
Es ist bewusst der schlechte Fall. Wir nehmen an, dass die Datenbank bereits geleakt ist, dass der Angreifer ernsthafte Hardware hat, dass die Seite dein Passwort auf die denkbar schlechteste vernünftige Weise gespeichert hat und dass er obendrein dein Alphabet und deine Länge kennt. Hat die Seite gut konfiguriertes bcrypt eingesetzt, steigt der reale Wert um viele Größenordnungen, und dein Passwort hält sehr viel länger durch, als wir dir sagen.
Wir irren uns lieber in diese Richtung. Ein Checker, der dir gratuliert, gratuliert vor allem sich selbst.
Das unbequeme Fazit
Dein Passwort hat keine Knackzeit. Es hat eine Knackzeit pro Seite, auf der du es benutzt hast, und die legen Leute fest, die du nicht kennst, nach Kriterien, die sie nicht veröffentlichen.
Daraus folgen zwei Dinge, und es sind die üblichen. Erstens: Weil du den Hash nicht kontrollieren kannst, kontrolliere die Entropie — das ist die Hälfte der Gleichung, die dir tatsächlich gehört. Deshalb zeigt dir der Generator Bits und keine nette Prozentzahl. Zweitens, und wichtiger: Wenn jede Seite ihr eigenes Passwort hat, kann die Seite mit dem MD5 auch nur das Passwort dieser einen Seite verschenken.
Denn das schwächste Glied ist nicht dein Passwort. Es ist die schlechteste Seite, auf der du es eingetippt hast.
Quellen: öffentliche hashcat-Benchmarks (hashcat -b), einsehbar und reproduzierbar · N. Provos und D. Mazières, „A Future-Adaptable Password Scheme“, USENIX, 1999 · Password Hashing Competition, 2015 von Argon2 gewonnen · das im Checker von password.es angegebene Bedrohungsmodell: 10¹² Versuche/s, offline, schneller Hash · LinkedIn-Datenleck von 2012: Das Unternehmen bestätigte den Leak, die Verwendung von SHA-1 ohne Salt wurde bei der Analyse des veröffentlichten Dumps festgestellt.