Brute-Force-Angriffe verstehen: Die Mathematik hinter dem Passwort-Knacken

Wie sicher ein Passwort wirklich ist, lässt sich in Bit Entropie und Hashes pro Sekunde rechnen. Eine RTX 4090 prüft MD5 mit 164 Milliarden Versuchen pro Sekunde, scheitert aber an Argon2id mit zwei Iterationen und 19 MiB Speicher. Dieser Beitrag erklärt die Suchraum-Mathematik, vergleicht aktuelle Hashcat-Benchmarks und ordnet ein, warum lange Passphrasen kurzen Komplexpasswörtern überlegen sind.

Suchraum: Die Grundgleichung

Ein Passwort der Länge n aus einem Alphabet der Größe k erzeugt einen Suchraum von k hoch n möglichen Kombinationen. Bei reinen Kleinbuchstaben (k = 26) und acht Zeichen ergibt das rund 209 Milliarden Möglichkeiten. Mit Großbuchstaben, Ziffern und 32 üblichen Sonderzeichen wächst k auf 94, der Suchraum springt auf etwa 6,1 Billiarden. Verdoppelt man die Länge auf 16 Zeichen bei kleinem Alphabet, landet man bei 4,4 mal 10 hoch 22 Möglichkeiten, deutlich über dem komplexen Acht-Zeichen-Wert.

Diese Asymmetrie ist der Kern der Passwort-Mathematik: Länge wirkt exponentiell auf die Basis hoch Länge, während Komplexität nur die Basis erhöht. Eine zusätzliche Stelle ist immer effizienter als ein zusätzlicher Sonderzeichen-Pool, weil sie die Zahl der Versuche um den Faktor k vervielfacht.

Entropie in Bit

Sicherheitsforscher messen Passwort-Stärke selten in absoluten Versuchszahlen, sondern in Bit Entropie. Die Formel lautet log2(k hoch n), also n mal log2(k). Ein zufälliges Acht-Zeichen-Passwort aus 94 Zeichen liefert 52,4 Bit, ein 16-Zeichen-Passwort aus dem gleichen Pool 104,8 Bit. Die EFF-Diceware-Methode mit fünf Wörtern aus einer 7776-Wörter-Liste erreicht ungefähr 64,6 Bit, sieben Wörter ergeben 90,5 Bit.

Ein Bit Entropie verdoppelt den Aufwand. Die Faustregel lautet: 80 Bit gelten als sicher gegen alle dokumentierten Brute-Force-Angriffe der nächsten Dekade, 100 Bit decken auch staatliche Akteure mit Spezialhardware ab. Diese Werte gelten allerdings nur für gleichverteilte Zufalls-Passwörter. Menschlich gewählte Passwörter weichen drastisch ab: Die Carnegie-Mellon-Studie "Guess Again" zeigte, dass selbst Passwörter, die formal 60 Bit Entropie hätten, real häufig in unter 30 Bit Aufwand fallen, weil Anwender Vornamen, Geburtsjahre und Tastaturmuster kombinieren.

Hashcat-Benchmarks: Was eine RTX 4090 kann

Die Hashcat-Foren publizieren Benchmarks für jede aktuelle GPU-Generation. Eine NVIDIA RTX 4090, derzeit Referenz im Cracking-Bereich, erreicht je nach Algorithmus dramatisch unterschiedliche Werte. MD5 ohne Salt läuft bei rund 164 Gigahashes pro Sekunde, NTLM bei 290 Gigahashes. SHA-256 fällt bereits auf 22 Gigahashes, weil der Algorithmus pro Hash deutlich mehr Rundenrechenzeit verbraucht.

bcrypt mit Cost 5 erreicht etwa 184 Kilohashes pro Sekunde, also rund eine Million Mal langsamer als MD5. Mit Cost 12, dem heutigen OWASP-Mindestwert, sinkt die Rate auf rund 22 Hashes pro Sekunde. Argon2id mit den OWASP-Default-Parametern liegt im niedrigen einstelligen Bereich pro Sekunde. Für einen Angreifer bedeutet das: Was bei MD5 in Sekunden scheitert, dauert bei Argon2id selbst auf einer Cluster-Konfiguration mit acht GPUs Jahre.

Knack-Dauer im Vergleich

Die Tabelle zeigt zwei Lehren. Erstens: Die Wahl des Hash-Algorithmus auf Server-Seite entscheidet stärker über die Sicherheit als die Komplexität des Passworts auf Anwender-Seite. Zweitens: Wer heute noch MD5 oder schnelles SHA-256 für Passwort-Speicherung nutzt, schützt seine Anwender praktisch nicht.

Wörterbuch-Angriffe: Der Realitätscheck

Reine Brute-Force-Angriffe gegen lange Passwörter sind selten. In der Praxis kombinieren Angreifer Wörterbücher mit Mutationsregeln. Die rockyou.txt aus dem RockYou-Leak von 2009 bildet die Basis, John the Ripper und Hashcat ergänzen sie um Regelsätze, die Buchstabentausch, Suffix-Anhängen und Groß-/Kleinschreibung-Permutationen ausführen. Ein typischer Lauf prüft 14 Millionen Wörter mit 65 Regeln, was 910 Millionen Kandidaten ergibt. Gegen MD5 läuft dieser Lauf in unter zehn Sekunden durch.

Maskenangriffe gehen einen Schritt weiter. Sie setzen voraus, dass ein Passwort einer bekannten Struktur folgt, etwa "Großbuchstabe + sechs Kleinbuchstaben + zwei Ziffern". Diese Annahme schränkt den Suchraum dramatisch ein und liefert hohe Trefferquoten gegen Passwörter, die naive Komplexitätsregeln erfüllen. Genau hier liegt der Konstruktionsfehler von Sonderzeichen-Pflicht ohne Mindestlänge: Anwender produzieren Muster, die Maskenangriffe optimal angreifen.

Suchraum gegen Passwort-Länge

Die Grafik macht den Trade-off sichtbar. Ein zufälliges 12-Zeichen-Passwort aus 94 Zeichen liefert 79 Bit Entropie, fünf Diceware-Wörter dagegen "nur" 65 Bit, sind aber merkbar. Erst bei sieben Diceware-Wörtern ist die merkbare Variante mit dem komplexen Zufallspasswort gleichauf. Genau diese Logik steht hinter dem berühmten XKCD-Comic 936, der 2011 die Idee popularisierte, Passphrasen wie "correcthorsebatterystaple" seien sowohl sicherer als auch besser merkbar als "Tr0ub4dor&3".

Warum lang wichtiger ist als komplex

Die XKCD-Logik lässt sich in drei Schritten formal nachvollziehen. Erstens: Ein 12-Zeichen-Passwort mit 94er Alphabet liefert 12 mal log2(94) gleich 78,6 Bit. Zweitens: Vier Diceware-Wörter liefern 4 mal log2(7776) gleich 51,7 Bit, sechs Wörter 77,5 Bit. Drittens: Beide Konstruktionen treffen sich rechnerisch knapp unterhalb von 80 Bit, der Diceware-Variante reichen aber 24 bis 30 Zeichen Tippaufwand, der komplexen Zufalls-Variante zwölf Zeichen mit hohem Memorierungsaufwand.

Für die Praxis folgt daraus: Master-Passwörter eines Passwort-Managers sollten Diceware-basiert sein, alle übrigen Konten erhalten zufällige 16- bis 20-Zeichen-Passwörter aus dem Generator des Managers, weil sie ohnehin nicht im Kopf liegen müssen. Die Sicherheitsindustrie hat diese Trennung übernommen: 1Password generiert standardmäßig 20-Zeichen-Passwörter, Bitwarden 14 Zeichen, beide bieten zusätzlich Passphrasen-Modi.

zxcvbn und die Strength-Meter

Salzen, Pfeffern und der Server-Anteil

Selbst der mathematisch beste Suchraum hilft nicht, wenn Server-seitig schludrig gespeichert wird. Drei Bausteine prägen die Server-Hygiene. Salt: Ein zufälliger, pro Konto eindeutiger Wert verhindert vorberechnete Rainbow-Tables. Pepper: Ein global gleicher, geheim gehaltener Wert wird zusätzlich in den Hash gemischt, sodass ein Datenbankleak ohne Code-Zugriff nutzlos ist. Iteration oder Speicher-Härte: Argon2id, bcrypt oder PBKDF2 erzwingen einen Mindestaufwand pro Hash-Berechnung, was Brute-Force unwirtschaftlich macht.

Wer einen dieser drei Bausteine weglässt, verschiebt das Problem auf die Anwender, die durch noch längere Passwörter kompensieren müssten. Das ist mathematisch möglich, aber praktisch unrealistisch. Verzeichnis-Studien wie der Verizon DBIR 2023 zeigen, dass 80 Prozent aller leak-bedingten Account-Übernahmen auf Konstellationen aus schwachem Server-Hashing und wiederverwendeten Anwender-Passwörtern zurückgehen.

Online vs. Offline: Zwei verschiedene Bedrohungsmodelle

Die Knack-Mathematik unterscheidet zwei grundlegend verschiedene Szenarien. Im Online-Angriff prüft der Angreifer Passwörter über die Login-Schnittstelle des Dienstes. Rate-Limits, Captchas und Konto-Sperren begrenzen die Versuche typischerweise auf wenige hundert pro Stunde. Selbst ein 8-stelliges Kleinbuchstaben-Passwort mit 38 Bit Entropie hält in diesem Modell mehr als 10.000 Jahre, sofern der Anbieter die Limits durchsetzt. Verizon DBIR 2023 zeigt allerdings, dass Credential-Stuffing dieses Modell aushebelt: Angreifer probieren keine Brute-Force-Kombinationen, sondern bereits geleakte Passwort-Anwender-Paare aus, die in 2 bis 4 Prozent der Fälle treffen.

Der Offline-Angriff ist dramatisch potenter. Hat der Angreifer die Hash-Datenbank, prüft er Kandidaten gegen den Hash ohne Rate-Limit. Die Hashcat-Werte aus der Tabelle gelten ausschließlich für dieses Szenario. Aus der Asymmetrie folgt eine doppelte Anforderung: Anbieter müssen einen Datenleak verhindern, sind aber gleichzeitig verpflichtet, Passwörter so zu hashen, dass sie auch im Leak-Fall nicht offline knackbar sind. Argon2id und vergleichbare speicher-harte Verfahren erfüllen diese zweite Anforderung, MD5 und unsalted SHA-256 nicht.

Cluster und Cloud: Wenn eine GPU nicht reicht

Professionelle Angreifer setzen nicht nur eine RTX 4090 ein, sondern Cluster von acht bis hundert Karten. Penetrationstest-Anbieter wie Hashcat-Maintainer Jens Steube haben Setups mit acht RTX 4090 dokumentiert, die zusammen rund 1,3 Terahashes pro Sekunde gegen MD5 erreichen. Cloud-Anbieter wie AWS und Vast.ai vermieten GPU-Instanzen ab wenigen Dollar pro Stunde, was die Eintrittshürde dramatisch senkt. Eine 24-Stunden-Session auf vier RTX-A100-Instanzen kostet rund 200 US-Dollar und liefert die mehrfache Leistung eines lokalen Acht-Karten-Setups.

Diese Verfügbarkeit verschiebt das Bedrohungsmodell. Was 2015 noch Spezialhardware bei spezialisierten Angreifern war, ist 2026 mit einer Kreditkarte zu mieten. Die OWASP-Empfehlung von Argon2id mit 19 MiB Speicher pro Hash zielt genau darauf: Speicher ist auf gemieteten GPU-Instanzen die teuerste Ressource, ein Verteidigungs-Hebel mit hoher ökonomischer Wirkung.

Rechenbeispiel: Der Weg vom Hash zum Passwort

Ein konkretes Szenario macht die Größenordnungen greifbar. Angenommen, ein Angreifer erbeutet die Hash-Datenbank eines mittelgroßen Forums mit 100.000 Konten, gespeichert als unsalted MD5. Mit einer einzelnen RTX 4090 prüft er gegen die rockyou.txt-Liste mit 14 Millionen Einträgen in unter 0,1 Millisekunden. In der Praxis bedeutet das: 30 bis 50 Prozent der Konten sind innerhalb von Sekunden offen, weil ein erheblicher Teil der Anwender Passwörter aus der Top-100.000-Liste verwendet hat. Schon der reine Wörterbuchangriff genügt, ohne überhaupt eine Brute-Force-Schleife zu starten.

Wechselt der Anbieter zu salted bcrypt mit Cost 12, kollabiert dieses Szenario. Der Angreifer kann keinen einzelnen Hash gegen das Wörterbuch prüfen, weil jeder Hash einen eigenen Salt trägt. Pro Konto und pro Wörterbucheintrag fällt eine bcrypt-Berechnung an, die rund 45 Millisekunden dauert. Der gleiche Angriff gegen 100.000 Konten würde rund 730 Jahre durchgehender GPU-Last erfordern, statt einer Sekunde. Dieser Faktor von rund 10 hoch 13 ist der praktische Unterschied zwischen einem fahrlässig und einem korrekt gespeicherten Passwort. Anwender beeinflussen ihn nicht, der Server-Betreiber allein.

Was die Mathematik vorgibt

Drei Größen entscheiden über die Knackbarkeit: Suchraum, Hash-Kosten und Wahl-Verhalten. Anwender beeinflussen den Suchraum durch Länge, Zufälligkeit und Verzicht auf Wörterbuch-Wörter. Server-Betreiber beeinflussen die Hash-Kosten durch Wahl von Argon2id und passender Parameter. Beide multiplizieren sich: Ein 16-Zeichen-Zufallspasswort hinter Argon2id ist außerhalb realistischer Angriffsbudgets, ein 8-Zeichen-Komplexpasswort hinter MD5 fällt vor dem Mittagessen. Die mathematisch konservative Empfehlung lautet: 80 Bit Entropie auf Anwender-Seite, OWASP-konformer Argon2id auf Server-Seite, Zwei-Faktor als zweite Verteidigungslinie. Wer diese drei Werte einhält, hat den Brute-Force-Angreifer auf das Niveau eines theoretischen Risikos zurückgedrängt.