Wie schnell knackt dein Computer ein Passwort? CPU gegen GPU im Praxistest

Ein Passwortprüfer kann einen grünen Balken zeichnen und eine beeindruckende Zahl von Jahren daneben schreiben. Mich interessiert an dieser Stelle etwas Handfesteres: Was tut dein eigener Computer tatsächlich, wenn er ein Passwort sucht? Welche Kandidaten erzeugt er, welche Hashes berechnet er und wie viel davon lässt sich sauber zählen?

Genau dafür gibt es jetzt das Password Cracking Lab im Museum. Du gibst ein erfundenes Passwort ein, bestimmst den Suchraum und lässt CPU, GPU oder beide gemeinsam arbeiten. Der Browser erzeugt den Ziel-Hash lokal. Die Such-Worker kennen das Originalpasswort nicht. Ohne echten Treffer gibt es auch keine Erfolgsmeldung.

01 — Offline raten heißt nicht, ein Konto anzugreifen

Bei einer Anmeldung entscheidet ein Dienst, ob und wann du den nächsten Versuch unternehmen darfst. Er kann Fehlversuche verzögern, Anfragen begrenzen, eine zweite Bestätigung verlangen oder eine Sitzung sperren. Wer dagegen einen Passwort-Hash besitzt, kann passende Kandidaten offline berechnen, ohne jede Vermutung beim Anmeldeserver einzureichen.

Unser Experiment bildet genau diesen Vergleich nach. Dein Browser erzeugt aus dem erfundenen Testpasswort einen SHA-256-Hash ohne Salt. Anschließend suchen lokale Worker nach einem Kandidaten mit demselben Hash. Sie greifen weder auf ein Benutzerkonto noch auf fremde Passwortdatenbanken oder entfernte Rechner zu.

Ein Treffer im Labor beweist deshalb nicht, dass damit die Anmeldung bei deiner Bank gelingt. Umgekehrt verhindert MFA nicht die Berechnung eines geleakten Passwort-Hashes. Sie kann bei der tatsächlichen Anmeldung eine zusätzliche Voraussetzung schaffen. Schutz der gespeicherten Daten und Schutz des Anmeldevorgangs sind zwei unterschiedliche Aufgaben.

02 — Ein Hash ist kein verschlüsseltes Passwort

Verschlüsselung soll sich mit dem passenden Schlüssel rückgängig machen lassen. Ein kryptografischer Hash besitzt keinen Entschlüsselungsschlüssel. SHA-256 erzeugt einen Digest mit 256 Bit, unabhängig davon, ob die Eingabe ein kurzes Wort oder eine lange Nachricht ist. Ein gefundenes Passwort wird nicht aus diesen Bits entschlüsselt.

Stattdessen entsteht für jeden Kandidaten ein neuer SHA-256-Hash. Die Suchmaschine vergleicht dessen acht Digest-Wörter mit dem Ziel. Meldet eine Engine einen Treffer, erzeugt der Koordinator den Kandidaten anhand seines Index erneut und kontrolliert ihn sowohl mit der CPU-Implementierung als auch mit Web Crypto. Erst danach erscheint „Passwort wiederhergestellt“.

Die entscheidende Frage lautet also: Wie viele plausible Eingaben müssen geprüft werden, und was kostet ein Versuch? Ein mathematisch großer Hashraum macht aus einem dreistelligen Zahlencode keinen unvorhersehbaren Geheimtext. Der Raum aller möglichen SHA-256-Ausgaben und der Raum deiner möglichen Passwörter sind verschiedene Dinge.

03 — Wörterbuch, Varianten und vollständige Suche

Ein Wörterbuchangriff beginnt mit einer festgelegten Sammlung plausibler Wörter. Das Labor bringt ein eigenes Lernwörterbuch mit 64 Einträgen mit, darunter katharina. Optional entstehen daraus Varianten mit großem Anfangsbuchstaben oder ausschließlich Großbuchstaben. Hinzu kommen numerische Suffixe mit einer bis vier Ziffern, einschließlich führender Nullen.

Damit kann die Suchmaschine katharina2482 finden, wenn du das Wörterbuch und passende Suffixe aktivierst. Der Name stand schon vor deiner Eingabe in der Liste. Die Ziffern werden systematisch erzeugt. Das Labor übernimmt niemals heimlich Teile des eingegebenen Passworts in sein Wörterbuch oder passt daran die Suchlänge an.

Die Beispielbuttons setzen ausdrücklich sichtbare Suchoptionen. Du könntest dieselben Einstellungen selbst wählen. Das ist ein nachvollziehbarer Versuchsaufbau: Erst wird definiert, welche Kandidaten gesucht werden, anschließend darf die Engine diesen Raum durchlaufen.

Die numerische Suche erzeugt alle Ziffernfolgen der gewählten Längen. Brute Force kombiniert die ausgewählten Ziffern, Kleinbuchstaben, Großbuchstaben und ASCII-Sonderzeichen in fester Reihenfolge. Der Smart-Modus beginnt mit Wörtern und kurzen Zahlen, prüft danach Wortsuffixe und längere Zahlen und geht schließlich zu den gewählten Brute-Force-Phasen über.

Unter dem Dashboard steht für jede Phase, was bereits bestätigt wurde. Eine abgeschlossene Suche nach drei Ziffern beantwortet eine konkrete Frage zu drei Ziffern. Sie sagt nichts über Umlaute, Emoji, unbekannte Wörter oder längere Zeichenketten aus. Ein abgebrochener Lauf ist kein Sicherheitszertifikat.

04 — Vor dem Tempo kommt der Suchraum

Bei fester Länge L und einem Alphabet mit A Zeichen gibt es A^L Kombinationen. Werden mehrere Längen durchsucht, werden ihre Kandidatenzahlen addiert. Führende Nullen gehören dazu: 007 und 7 sind unterschiedliche Eingaben.

Das sind berechnete Suchraumgrößen, keine gemessenen Geschwindigkeiten. Ein von einem Menschen gewähltes Passwort ist außerdem nicht automatisch gleichmäßig über seinen vermeintlichen Zeichensatz verteilt. Ein vertrauter Name mit angehängtem Datum stellt ein anderes Suchproblem dar als eine zufällig erzeugte, einmalige Zeichenfolge gleicher Länge.

Die interne Verwaltung benutzt für Indizes und Gesamtzahlen JavaScript-BigInt. Das bleibt auch dann exakt, wenn der Suchraum die präzise darstellbaren normalen JavaScript-Zahlen übersteigt. Prozente und Zeitangaben dürfen für die Anzeige gerundet werden; die Zuordnung der Kandidatenbereiche darf das nicht.

05 — Was CPU, GPU und Hybrid wirklich rechnen

Im CPU-Modus laufen Erzeugung und Hash-Prüfung in eigenen Web Workern. Die Bedienoberfläche bleibt auf ihrem Thread und kann weiterhin reagieren. Du begrenzt die Anzahl der Worker und die Rechenintensität. Zusätzliche Worker können mehr Durchsatz liefern, konkurrieren aber auch mit Spielen, anderen Tabs und den Aufgaben deines Betriebssystems.

Der GPU-Modus fordert einen WebGPU-Adapter und ein Gerät an, übersetzt einen WGSL-Compute-Shader und führt darin echte SHA-256-Runden aus. Jede Shader-Invocation prüft einen vorbereiteten Kandidaten. Vorher müssen die Eingabepuffer erzeugt und übertragen werden, anschließend muss der Browser das Ergebnis zurückholen.

Eine GPU ist dabei nicht automatisch schneller. Kleine Batches, Übertragungsaufwand, Browserplanung, der tatsächlich ausgewählte Adapter und andere Last können das Ergebnis verändern. Deshalb zeigt das Labor keinen festen GPU-Beschleunigungsfaktor. Es misst abgeschlossene Arbeit. Steht nur ein Softwareadapter zur Verfügung, bleiben GPU und Hybrid in der normalen Oberfläche deaktiviert.

Hybrid bedeutet tatsächlich gleichzeitige Berechnung. Ein gemeinsamer Koordinator verteilt verschiedene Indexbereiche auf CPU- und GPU-Worker. Sobald eine Engine ihren Batch bestätigt, erhält sie weitere Arbeit. Eine schnellere Engine bekommt dadurch mehr Bereiche, ohne dass die langsamere dieselben Indizes noch einmal prüft.

Geht die GPU verloren, endet der Lauf mit einer ausdrücklichen Fehlermeldung. Es folgt kein versteckter CPU-Ersatz unter einem GPU-Etikett. Die Vorbereitung der GPU-Kandidaten benötigt allerdings weiterhin CPU-Arbeit im Worker. „GPU“ bezeichnet hier die SHA-256-Prüfungen im Shader, nicht die Behauptung, dass kein anderer Teil des Computers beteiligt wäre.

Das ist auch beim Vergleich mit ausgereiften nativen Werkzeugen wie John the Ripper wichtig. Unser Browser-Labor ist ein nachvollziehbarer Versuch mit klar begrenzten Kandidaten und einem Hashverfahren, kein Ersatz für deren umfangreiche Formate und optimierte Angriffsmöglichkeiten.

06 — Eine Schätzung verspricht keinen Trefferzeitpunkt

Vor einem Angriff laufen zunächst getrennte Aufwärmbatches und danach echte Messbatches. Das Labor teilt die konfigurierte Kandidatenzahl durch den gemessenen Durchsatz und schätzt damit eine vollständige Suche. Während des Angriffs fließen die tatsächlich abgeschlossenen Versuche in die Schätzung ein. Es gibt keine eingebaute Drei-Sekunden-Erfolgsszene.

Die Suchmaschine weiß nicht, an welcher Stelle der richtige Kandidat steht. Er könnte früh kommen, ganz am Ende stehen oder im gewählten Raum fehlen. Den Suchraum einfach zu halbieren würde nur unter weiteren Annahmen eine erwartete Position beschreiben. Es würde nicht den Fundzeitpunkt deines konkreten Testpassworts berechnen.

Deshalb ändert eine andere Passworteingabe allein nicht zwingend die erste Schätzung. Bei identischer Konfiguration bleibt derselbe Raum zu durchsuchen. Vorhersehbare Namen oder Ziffernanhänge werden erst dann günstig, wenn eine passende Strategie solche Muster früh einplant. Das Labor leitet diese Strategie nicht aus dem geheimen Original ab.

Die Kalibrierung hat einen eigenen Zähler. Aufwärmversuche zählen nicht zur gemessenen Kalibrierung, und Kalibrierungsversuche erhöhen nicht den Angriffszähler. CPU- und GPU-Beiträge werden über dasselbe tatsächlich gemessene Zeitfenster einschließlich Intensitätspausen berechnet. So ergibt ihre Summe den gemeinsamen Messdurchsatz.

Die aktuellen Raten entstehen aus bestätigten Kandidaten in einem laufenden Zeitfenster. Am Ende zeigt das Dashboard den Durchschnitt aus bestätigten Versuchen und tatsächlich verstrichener Angriffszeit. Initialisierung, Kalibrierung, bewusste Pausen und die abschließende unabhängige Trefferprüfung zählen nicht zu dieser Laufzeit.

Ein abgeschlossener Batch zählt vollständig, auch wenn eine seiner Shader-Lanes einen Treffer gefunden hat. Andere Worker können schon eigene Bereiche bearbeiten. Der Zähler behauptet deshalb nicht, sämtliche Engines hätten exakt beim ersten passenden Hash angehalten. Er zeigt die Arbeit, die wirklich abgeschlossen wurde.

07 — Gute Passwortspeicherung macht jeden Versuch teuer

SHA-256 ist bewusst schnell. Für viele kryptografische Aufgaben ist das sinnvoll, für Passwortspeicherung allein ist es eine ungünstige Eigenschaft. Der Lernhash im Labor lässt die teuren Bestandteile absichtlich weg, damit sich der Zusammenhang zwischen Kandidatenraum und Berechnung beobachten lässt.

Ein eigener Salt unterscheidet gespeicherte Passwort-Hashes voneinander und verhindert, dass eine einzige vorberechnete Tabelle identisch auf alle Konten passt. Er macht ein vorhersehbares Passwort jedoch nicht unvorhersehbar und verhindert keine Vermutungen gegen einen einzelnen bekannten Hash.

Moderne Passwort-Hashverfahren wie Argon2id erhöhen gezielt Rechen- und Speicheraufwand. Dadurch ändern sie auch, wie viele Versuche gleichzeitig wirtschaftlich durchgeführt werden können. Die schnelle SHA-256-Rate aus diesem Experiment ist keine Argon2id-Knackrate. Einen ehrlichen, universellen Umrechnungsfaktor gibt es nicht.

Für eine echte Anwendung gehören eine gepflegte Implementierung, aktuelle Empfehlungen zur Passwortspeicherung und zur eigenen Infrastruktur passende Parameter zusammen. Dieses Museumsexperiment erklärt die Unterschiede; es ist kein Bauplan für eine produktive Passwortdatenbank.

08 — Ein sinnvoller kleiner Praxistest

1. Öffne das Labor und wähle das erfundene Beispiel 123. Es setzt ausdrücklich die numerischen Längen 1–3.
2. Miss zuerst die Leistung und starte danach den Angriff. Beobachte bestätigte Kandidaten und Laufzeit, statt die Schätzung mit dem Trefferzeitpunkt gleichzusetzen.
3. Teste katharina2482 mit aktivierten Wörterbuchsuffixen. Schau nach, welche Phasen wirklich abgeschlossen wurden.
4. Wähle einen kleinen, absichtlich unpassenden Suchraum und beobachte den ehrlichen Abschluss ohne Treffer.
5. Falls ein physischer WebGPU-Adapter verfügbar ist, vergleiche CPU, GPU und Hybrid mit denselben Such- und Intensitätseinstellungen. Wiederhole die Messung, wenn sich die Gerätelast verändert.

Längere Läufe werden nicht nach einer kurzen Demonstrationszeit beendet. Pausieren lässt bereits zugewiesene Batches abschließen und erhält die Sitzung im Arbeitsspeicher. Fortsetzen arbeitet mit derselben Bereichsverwaltung weiter. Stoppen beendet die Berechnungen, Zurücksetzen löscht die zielbezogene Sitzung und einen eventuell eingeblendeten Treffer.

Beim Verbergen des Tabs pausiert die Seite einen laufenden Angriff. Ein geschlossener, angehaltener oder stark gedrosselter Browser ist kein verlässlicher Hintergrund-Rechendienst. Lange Suchen kosten außerdem Energie und erzeugen Wärme. Auf Smartphone und Laptop sind zurückhaltende Einstellungen sinnvoll. Die erzeugten Kandidaten sind ausdrücklich auf ASCII und 1–24 Zeichen begrenzt.

09 — Was du für echte Konten mitnehmen kannst

Ein Passwortmanager hilft dabei, für jeden Dienst ein eigenes, generiertes Passwort zu verwenden, statt bekannte Wörter immer wieder leicht abzuwandeln. Wiederverwendung schafft ein zusätzliches Problem: Ein bei einem Dienst bekannt gewordenes Passwort kann bei anderen ausprobiert werden, ohne dort erst einen neuen Hash knacken zu müssen.

Wo Dienste Passkeys unterstützen, können sie das gemeinsam bekannte Passwort ersetzen. Geeignet umgesetzte Authentifizierungsverfahren können außerdem Phishing widerstehen. Wo Passwörter bleiben, helfen einmalige generierte Zugangsdaten und ein passender zweiter Faktor. Vergiss dabei die Wiederherstellungswege und das Gerät mit deinen Zugangsdaten nicht.

Die eigentliche Erkenntnis dieses Experiments liegt im Zusammenhang zwischen Suchreihenfolge, Vorhersehbarkeit, Hashkosten und gemessener Hardwareleistung. Ein schneller Treffer zeigt einen echten Vergleichsvorgang. Ein Lauf ohne Treffer verrät nur, was tatsächlich geprüft wurde. Das ist eine brauchbarere Grundlage als ein grünes „sicher“-Etikett.

Quellen und weiterführende Informationen

Implementierung und Grenzen des Labors sind im Repository dokumentiert. Diese Primärquellen erläutern Hashverfahren, Browser-Schnittstellen und die Unterschiede zur echten Passwortspeicherung.

• NIST FIPS 180-4: Secure Hash Standard
• W3C: WebGPU Shading Language
• MDN: WebGPU-Adapter und Verfügbarkeit
• OWASP: Password Storage Cheat Sheet
• RFC 9106: Argon2
• NIST SP 800-63B: Authentifizierung und Verwaltung von Authentifikatoren

Dein Passwort. Deine Hardware. Deine Privatsphäre. Zum Labor →