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örterbücher und echte blinde Suche

Das Labor bietet vier unabhängige Suchmethoden: deutsches Wörterbuch, englisches Wörterbuch, typische Passwörter & IT und Brute Force. Deutsch und Englisch sind standardmäßig aktiv; typische Passwörter/IT und Brute Force sind optional. Die deutsche Sammlung umfasst 213.096 Basiseinträge (211.575 Wörter und 1.521 Wortkombinationen), die englische 249.223 (247.725 Wörter und 1.498 Wortkombinationen). Namen, Ortsnamen und internationale Technikbegriffe überschneiden sich bewusst. Die Sprache der Website beeinflusst die Auswahl nicht.

Für jede gewählte Sammlung entstehen feste Schreibweisen: Original, Anfangsbuchstabe groß, GROSSBUCHSTABEN und zwei vollständige Leetspeak-Formen mit denselben Groß-/Kleinschreibungen. Doppelte Formen werden pro Phase entfernt. Die Suche prüft zuerst beide gewählten Grundsammlungen, danach die Jahre 1984–2035, dann einstellige und zweistellige Ziffernsuffixe einschließlich führender Nullen. Das ergibt 1.729.310 deutsche und 2.072.347 englische Grundformen; alle Wörterbuchphasen zusammen umfassen 619.670.091 tatsächliche Hashprüfungen.

Brute Force zählt anschließend jede Kombination aus allen 95 druckbaren ASCII-Zeichen einschließlich Leerzeichen auf, zuerst Länge 1, dann 2 und so weiter bis 24. Es gibt keinen verkürzten Zahlensuchraum, keine Anpassung an die tatsächliche Länge und keine aus der Eingabe übernommenen Zeichen. Das eingegebene Passwort erzeugt ausschließlich den lokalen SHA-256-Zielhash.

Ein Wort wie penis stammt aus dem fest gebündelten Körpervokabular. sommer2024 kann über das deutsche Wort und die feste Jahresphase gefunden werden. A1h5 gehört zum Brute-Force-Raum; dafür muss die Suche alle früheren Kombinationen wirklich prüfen. Beispiele bestimmen weder Priorität noch Garantien. Der Suchplan ist bei gleichen Schaltern identisch, unabhängig vom Passwort. Ein vollständiger oder gestoppter Lauf ist kein Sicherheitszertifikat.

Das größere deutsche Wörterbuch nutzt 210.000 ausgewählte Wörter aus enz/german-wordlist (CC0), zusätzlich zu den Lehrwörtern. Die Auswahl bevorzugt kurze Wörter, sortiert nach Länge und Alphabet; sie beansprucht nicht, alle deutschen Wörter abzudecken. Englisch ergänzt die passenden Grundwörter aus dem offiziellen SCOWL/ESDB-US-Wörterbuch 2026.02.25, mit den ausdrücklich hinterlegten Hunspell-Vorsilben und Endungen, beim Build aufgezählt. Hinzu kommt die lizenzierte ESDB-Auswahl 2026.02.25 bis Stufe 80 mit US/GB/Kanada-Schreibweisen, einschließlich seltenerer gültiger Wörter und kuratierter Alltagsbegriffe. Beide Quellen werden für den dokumentierten ASCII-Suchraum transliteriert und dedupliziert.

Der neue Schalter „Typische Passwörter & IT“ enthält 26.652 Basiseinträge aus der öffentlichen SecLists-Common-Credentials-Liste und festem IT-Vokabular, ergänzt um kuratierte Namen, Filme, Spiele, Hobbys und 15.000 Vornamen aus aggregierten SSA-Statistiken (US Public Domain). Es wurden keine neuen geleakten Zugangsdaten importiert. Das ist eine veröffentlichte Testliste, keine aktuelle Beliebtheitsstatistik. Ist sie gewählt, beginnen die Phasen mit ihr, gefolgt von DE und EN. Sie benötigt mit den festen Transformationen und Suffixen insgesamt 34.499.439 echte Hashprüfungen. Größere Wörterbücher bedeuten mehr Abdeckung und mehr Rechenarbeit; die gebündelten Listen benötigen auch mehr Speicher. Quellenstand und Verarbeitung sind dokumentiert.

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.

Die Jahresregeln beginnen jetzt bei 1984 und reichen bis mindestens 2035; nach 2035 wächst die Obergrenze mit dem Kalenderjahr, begrenzt auf vier Ziffern. Bekannte Namen wie Bud Spencer und deutsche Zusammensetzungen sind Teil einer festen, kuratierten Themenauswahl. Kein Kandidat wird aus der eingegebenen Zeichenfolge abgeleitet. Ein fehlender Wörterbuchtreffer beweist keine Sicherheit.

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 versucht WebGPU zuerst im Worker. Kann dieser Kontext nicht starten, prüft das Labor den Hauptthread unabhängig, bereitet Kandidaten in einem eigenen Worker vor und übergibt echte GPU-Arbeit asynchron. Die Adapteranfragen versuchen High Performance, die Standardauswahl und den Compatibility-Modus; die Unterstützung im Browser entscheidet weiterhin über die Verfügbarkeit. Ausgewählter Pfad und genaue Fehlerstufe stehen in der aufklappbaren Diagnose. Ein nutzbarer Pfad fordert ein GPU-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-Worker und den ausgewählten GPU-Pfad. 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, gib ein erfundenes Passwort ein und wähle CPU, GPU oder Hybrid. Starte mit niedriger Gerätebelastung.
2. Teste dasselbe erfundene Wort, etwa penis, mit Wörterbüchern und danach mit ausschließlich Brute Force. Die Schalter ändern nur den vorher festgelegten Suchraum.
3. Vergleiche sommer2024 mit A1h5. Beobachte die gewählte Methode, aktuelle Phase, echte Versuche pro Sekunde und bestätigte Trefferzeit. Warte bei Brute Force nicht auf einen garantierten schnellen Treffer.
4. Teste ausschließlich ein Wörterbuch mit einem erfundenen Wert außerhalb seiner Muster. Erst die vollständige Prüfung ergibt „nicht im gewählten Suchraum gefunden“.
5. Vergleiche verfügbare Hardwaremodi mit denselben Schaltern. Kalibrierung läuft beim Start automatisch. Pause hält die Sitzung; Stop beendet sie; Reset löscht das lokale Ergebnis.

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. Brute-Force-Kandidaten sind auf ASCII und 1–24 Zeichen begrenzt; Wörterbuchmuster können 24 ASCII-Zeichen erreichen. Die Eingabe wird exakt als UTF-8 gehasht, niemals normalisiert.

Du hast wirklich das Passwort einer eigenen ZIP-, RAR-, 7Z- oder PDF-Datei vergessen? Das ist etwas anderes als die SHA-256-Demonstration dieses Artikels. Im Archive Recovery Lab werden unterstützte verschlüsselte Dateien lokal im Browser geprüft, entschlüsselte Inhalte unabhängig verifiziert und ohne Upload der ausgewählten Datei zum Download angeboten. Verwende es ausschließlich für eigene oder ausdrücklich freigegebene Dateien. CPU ist Standard; für geeignete ZIP-/RAR5-Varianten sind GPU und Hybrid manuell wählbar.

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 →