Was eine lokale Liste schwacher Passwörter beweisen kann – und warum das kein netzweiter Leak-Abgleich ist

Kein Treffer heißt nicht „nie geleakt“

Lokale Prüfungen liefern meist eines von zwei Ergebnissen: Treffer oder kein Treffer. Ein Treffer ist leicht zu nutzen. Die Zeichenkette steht bereits auf einer öffentlichen Häufigkeitsliste; wer sie behält, bleibt in der ersten Charge, die Angreifende ausprobieren. Beim Fehlschlag legen viele eine zweite Behauptung drauf: Die Liste komme aus „Leaks“, also müsse kein Treffer „sauber“ bedeuten.

Eine Liste kann nur für die Zeilen sprechen, die sie enthält. Ein interner Dump, der nie veröffentlicht wurde, ein Infostealer-Protokoll, das noch in keinem öffentlichen Korpus landet, oder ein Passwort, das nur von einer kleinen Site gestohlen und nie weitergegeben wurde, erscheint nicht in den paar Hundert oder Tausend Zeilen, die ein Tab gerade geladen hat. Die ehrliche Lesart eines Fehlschlags lautet: Unter dieser lokalen Liste und dieser Vergleichsregel wurde die exakte Zeichenkette – oder die wenigen Varianten, die das Skript kennt – nicht gefunden. Dieser Satz hat nie „das ganze Netz“ versprochen.

Schreiben Sie diese Grenze auf, bevor Sie den nächsten Schritt festlegen. Ein Treffer ist ein Grund zum Wechseln. Ein Fehlschlag lässt Länge, Wiederverwendung und die Frage offen, ob ein Passwortmanager die Zeichenkette erzeugt hat. Die Liste ist ein Filter. Sie ist kein Unschuldsbeweis.

Gegen welche Art von Raten die Liste überhaupt hilft

Angreifende laufen selten von a bis zzzz…. Die zwei üblichen Wege sind Credential Stuffing – geleakte Benutzername-Passwort-Paare auf anderen Sites – und Online-Raten, das oben auf öffentlichen Ranglisten schwacher Passwörter beginnt. 123456, password und qwerty stehen dort vorn, weil sie oft gewählt werden, nicht weil sie „kurz aussehen“. Ein paar Versuche reichen oft.

Eine Häufigkeitsliste zielt auf genau diese Schicht. Sie markiert Zeichenketten, die schon übernutzt sind, solange Sie sie noch ändern können. Sie beantwortet nicht, wie groß der Suchraum ist, und sie beantwortet nicht, ob irgendein unveröffentlichtes Korpus genau diese Zeile schon hat. Das sind Entropieschätzung und ein viel größeres Leak-Korpus. Beides darf nicht mit „sieht das wie ein gängiges schwaches Passwort aus“ zu einem Urteil verschmelzen.

Deshalb bleibt eine Liste nützlich, die gar nicht besonders lang ist. Online-Logins sind fast immer gedrosselt. Bis das Konto sperrt, bleibt nur ein kleines Budget – also werden die ranghöchsten Passwörter zuerst versucht. NIST SP 800-63B-4 schreibt den Zweck einer Blocklist so: Passwörter stoppen, die mit hoher Wahrscheinlichkeit erraten werden, bevor die Drosselung greift. Ist die Liste für dieses Ziel groß genug, bringen Extra-Zeilen wenig, weil der Online-Angriff ohnehin gebremst wird. Eine lokale Häufigkeitsliste ist für dieses Ziel gebaut. Sie ist nicht dafür entworfen, jedes jemals geleakte Passwort zu enthalten.

NIST will den ganzen String prüfen – keine extra Komplexitätsregeln

Das US-amerikanische National Institute of Standards and Technology formuliert in SP 800-63B-4 den Vergleich als Pflichtschritt für die Stelle, die ein Passwort annimmt: Beim Anlegen oder Ändern muss der gesamte Kandidat gegen eine Blocklist häufig genutzter, erwartbarer oder kompromittierter Passwörter geprüft werden. Die Prüfung lautet nicht „steckt irgendwo ein Wörterbucheintrag“ und nicht „fehlt ein Sonderzeichen“. Ein Treffer muss abgelehnt werden, und die Nutzerin oder der Nutzer muss den Grund erfahren.

Derselbe Abschnitt schreibt die Passwortrichtlinie um, die mehr als zehn Jahre lang falsch verstanden wurde. Prüfende Stellen dürfen keine Mischung aus Großbuchstaben, Ziffern und Sonderzeichen erzwingen. Sie dürfen keinen periodischen Wechsel verlangen, solange es keinen Hinweis gibt, dass genau dieser Authenticator kompromittiert wurde. Als einziger Faktor muss ein Passwort mindestens 15 Zeichen haben; als ein Faktor in der Mehrfaktor-Authentifizierung liegt die Untergrenze bei 8. Diese Sätze richten sich an Sites, die Passwörter entgegennehmen, nicht an eine Selbstprüfung im Browser. Wer ein Prüfergebnis liest, hat trotzdem etwas davon: Häkchen bei Komplexität beweisen keine Sicherheit. Als Erstes lohnt sich das Blockieren eines ganzen Strings, der schon auf einer öffentlichen Liste steht.

Im deutschsprachigen IT-Grundschutz sagt das BSI in ORP.4.A8 sinngemäß dasselbe: Passwörter, die leicht zu erraten sind oder in gängigen Passwortlisten geführt werden, dürfen nicht verwendet werden. Das ist eine Sperrlisten-Anforderung an den ganzen String – kein Auftrag, im Browser Have I Been Pwned aufzurufen. Wer „Liste schwacher Passwörter“ und „Leak-Abgleich im ganzen Netz“ in einen Satz packt, vermischt zwei Pflichten mit sehr unterschiedlicher Datenlage.

NIST erinnert außerdem daran, nach einer Ablehnung Hinweise zu geben, damit niemand bei der Umschreibung password → Password1 stehen bleibt. Prüft eine lokale Liste zusätzlich Groß-/Kleinschreibung, zwei oder drei angehängte Ziffern und gängiges Leetspeak (@ für a, 0 für o), zielt sie genau auf diese Umschreibungen. Das bleibt eine Heuristik, kein kryptographischer Beweis. P@ssw0rd2026! kann auffallen. Eine Umschreibung, die in den Regeln nicht vorkommt, fällt nicht auf.

Kurze lokale Liste, Hashpräfix-Abfrage und volles Offline-Korpus

„War das schon geleakt?“ sind mindestens drei Verfahren. Wer sie vermischt, macht aus einem Fehlschlag „nie geleakt“. Der Unterschied steckt nicht im Slogan. Er steckt darin, welche Daten das Gerät verlassen und was ein Server sehen kann.

Das erste Verfahren ist eine kurze lokale Liste. Die Seite lädt eine öffentliche Textdatei in den aktuellen Tab, das Skript baut im Speicher eine Menge und sucht den ganzen eingegebenen String plus ein paar Varianten. Die ausgehende Anfrage ist die Listendatei, nicht das geprüfte Passwort. Die Abdeckung entspricht der Zahl nicht leerer Zeilen. Nehmen Sie die Datei leaked-top10k.txt, die MakePwd mit der Prüfung ausliefert. Der Dateiname sagt top10k. Öffnen Sie die Antwort und zählen Sie selbst – derzeit stehen dort rund 860 häufige Einträge, nicht 10.000 und nicht das ganze Netz. Schlägt das Laden fehl, fällt die Umsetzung auf eine winzige eingebaute Menge zurück (etwa password und 123456). Die Abdeckung schrumpft. Die Prüfung bleibt auf diesem Gerät.

Das zweite Verfahren ist die Pwned-Passwords-Bereichsabfrage von Have I Been Pwned. Die offizielle Beschreibung nennt ein Korpus aus Hunderten Millionen Passwörtern, die in Leaks vorkamen. Der Client hasht lokal mit SHA-1 (oder NTLM) und schickt nur die ersten fünf hexadezimalen Zeichen an https://api.pwnedpasswords.com/range/{prefix}. Danach vergleicht er die zurückgegebenen Suffixe mit dem vollständigen Hash, den er schon berechnet hat. Nach Entwurf gehen weder Klartext noch der komplette Hash raus. Das ist k-Anonymität: Der Server erfährt nur, in welchem von rund einer Million Präfix-Eimern (16⁵) Sie gelandet sind. Es bleibt eine externe Abfrage. Abgefragt wird nicht das Passwort selbst. Im November 2025 hat HIBP rund 1,3 Milliarden eindeutige Passwörter aus dem Synthient-Credential-Stuffing-Korpus aufgenommen, davon rund 625 Millionen neu für diesen Dienst. Im Juni 2026 kamen rund 124 Millionen eindeutige Passwörter aus Stealer-Logs hinzu. Diese Zahlen zeigen, dass das Korpus wächst. Sie bedeuten nicht „einmal geprüft, für immer sauber“.

Das dritte Verfahren: das volle Korpus auf die eigene Maschine oder ins eigene Netz laden und offline vergleichen. HIBP stellt diesen Download ebenfalls bereit. Die Abdeckung liegt nahe am zweiten Verfahren, aber es geht kein Präfix an api.pwnedpasswords.com. Der Preis sind Updates, Speicher und der Hash-Index, den Sie selbst pflegen. Deutschsprachige Anleitungen zur „lokalen HIBP-Datenbank“ meinen genau diesen dritten Weg – nicht die kurze Häufigkeitsliste einer Tool-Seite.

Keiner dieser drei Sätze lässt sich umschreiben in „dieses Passwort ist in keinem Leak je vorgekommen“. Unveröffentlichte Dumps, noch nicht aufgenommene Logs und ein Passwort, das Sie nie an Dritte gegeben haben, liegen außerhalb der Pflicht jeder Sammlung. Eine lokale Liste ist die engste der drei. Ihr Vorteil: Das geprüfte Passwort muss den Tab nicht verlassen.

Was Treffer und Fehlschlag jeweils stützen

Ein Treffer trägt einen harten Satz: Diese Zeichenkette steht bereits auf einer öffentlichen Häufigkeitsliste, oder sie ist nur eine Umschreibung, die die Liste erkennt. Wer sie weiter nutzt, bleibt in der Menge, die Credential Stuffing und Online-Raten zuerst versuchen. Der richtige Schritt ist Wechseln – und dieselbe Zeichenkette nicht auf anderen Sites wiederzuverwenden.

Ein Fehlschlag braucht einen Geltungsbereich. Er stützt „das sieht auf dieser Liste nicht wie ein gängiges schwaches Passwort aus“. Er stützt nicht „es wurde nie gedumpt“, „es darf überall wiederverwendet werden“ oder „die Entropie reicht“. Ein 20 Zeichen langes Zufallspasswort gibt keinen Treffer. Ein Passwort, das nur in einem unveröffentlichten Dump vorkam, ebenfalls nicht. Der Chip auf der Seite sieht gleich aus. Die Bedeutung nicht.

Es gibt außerdem den Fall, der lang wirkt und trotzdem als schwach markiert werden muss. Ein Listentreffer steht über der Entropie. password hat acht Buchstaben, eine Zeichensatzschätzung liefert also eine Bit-Zahl ungleich null – und trotzdem versucht es jede Angreiferin zuerst. Setzt eine lokale Prüfung die Stufe nach einem Treffer auf schwach, liegt der Grund in der Liste, nicht in einer kaputten Bit-Formel. Umgekehrt gilt dasselbe. Fehlschlag plus hohe Entropie stützt nur „es wirkt nicht gängig, und Durchprobieren wirkt teuer“. Das ist nicht „schon sicher“. Wiederverwendung, Phishing und eine Site, die Klartext speichert, liegen außerhalb dieses Vergleichs.

Sofort prüfen: zuerst die Listendatei, dann Network

„Lokal verglichen, nichts hochgeladen“ beweist sich nicht selbst. Was Sie sofort sehen können, sind zwei Dinge: welche Listendatei der Browser geladen hat, und ob die eingegebene Zeichenkette als Geschäftsdaten den Tab verlassen hat.

Beginnen Sie mit der Liste. Öffnen Sie DevTools Network, filtern Sie nach einer Anfrage, deren Name leaked oder top enthält, und speichern Sie die Antwort als Text. Zählen Sie in einem Editor die nicht leeren Zeilen. Prüfen Sie die ersten Zeilen stichprobenartig auf öffentliche Häufigkeitspasswörter wie 123456 und password. Die Zeilenzahl, die Sie selbst gezählt haben, ist der Nenner hinter „kein Treffer“. Schreiben Sie nicht „10.000 Einträge“, nur weil der Dateiname 10k enthält.

Dann das geprüfte Passwort. Legen Sie einen Canary an, der in echter Arbeit nie vorkommt, etwa canary-audit-2026-x7k, und tippen Sie ihn in die Prüfung. Aktivieren Sie Preserve log und fügen Sie diese Zeichenkette in den Filter ein. Sie darf in keiner XHR-/Fetch-Anfragezeile, keinem Query-String und keinem Body stehen. Sie darf auch in keiner Analytics-Query und keinem Analytics-Body stehen. Statische Ressourcen, Schriften und die Listendatei dürfen erscheinen – dass die Liste den Ursprung verlässt, ist erwartet. Dass das geprüfte Passwort den Tab verlässt, ist ein Fehlschlag.

1. Network öffnen, Preserve log aktivieren, eine Prüfung durchführen, dann die Antwort der Listendatei finden und die Zeilen zählen.
2. Die Prüfung mit einem Canary-Passwort wiederholen und den Filter nach dieser Zeichenkette durchsuchen. Ein Treffer in irgendeiner Anfrage heißt: Klartext hat den Tab verlassen.
3. Gibt es keinen Treffer, Analytics-Anfragen öffnen und prüfen: Titel und Pfade dürfen vorkommen, der volle Text aus dem Eingabefeld nicht.

Was das stützt, ist eng: In diesem Lauf hat das geprüfte Passwort den aktuellen Tab nicht als beobachtetes HTTP-Feld verlassen, und die Listenabdeckung entspricht den gezählten Zeilen. Es beweist nicht, dass keine Erweiterung das Eingabefeld gelesen hat, und es beweist nicht, dass nächste Woche dasselbe Skript gleich arbeitet. Wechseln Sie Browser oder Version, lohnt sich die Canary-Suche erneut.

Entropie und Liste beantworten verschiedene Fragen

Eine Prüfseite zeigt oft Stufe, Bit-Zahl und Listentreffer nebeneinander. Wer das als eine Note liest, stolpert, wenn die Bits in Ordnung wirken, die Liste aber trifft – oder wenn es keinen Treffer gibt, die Zeichenkette aber kurz ist. Sie beantworten verschiedene Fragen. Sie dürfen sich nicht gegenseitig aufheben.

Entropie fragt: Wenn jemand den Zeichensatz durchprobiert, wie lange dauert das im Mittel? Eine übliche Formel ist Länge mal log2(Zeichensatzgröße), danach ein Abschlag für Wiederholungen oder lange Läufe desselben Zeichens. Stehen die Schwellen bei ≥ 80 Bits für sehr stark, ≥ 60 für stark, ≥ 40 für mittel und dem Rest schwach, sind das Fächer dieser Schätzfunktion. Es sind keine Labor-Knackzeiten. Offline- und Online-Zeitleisten nutzen außerdem verschiedene Raten – zum Beispiel 10¹⁰ Versuche pro Sekunde offline und 10³ online, dann der Mittelwert (die Hälfte des Suchraums). Ändern Sie die Rate, ändert sich die Zeit. Das Passwort nicht.

Die Liste fragt: Ist diese Zeichenkette schon öffentlich übernutzt? Sie nutzt die Bit-Zahl nicht. Ein Listentreffer bleibt schwach, auch wenn zufällig ein Großbuchstabe und ein Sonderzeichen drin sind. Ein sechs Zeichen langer Fehlschlag hat niedrige Entropie, und die Länge allein drückt ihn auf schwach – das hat nichts mit einem Leak-Korpus zu tun. Ein Hinweis „schwächer als nötig“ unter 8 Zeichen ist eine Längenwarnung, keine Leak-Datenbank-Warnung.

Eine vollständige Lesart schaut also an mindestens drei Stellen: ob die Liste getroffen hat, ob die Zeichenkette zu kurz ist, und in welchem Entropie-Fach sie landet. Erst danach können Sie sagen, „wie diese Zeichenkette gerade wirkt“. Das ersetzt weiterhin keinen Passwortmanager und nicht die Regel „pro Site ein Zufallspasswort“.

Die Grenze an einer sofort nutzbaren Prüfung einüben

Wenn Sie eine Seite wollen, die die Grenze offen hinschreibt, beginnen Sie mit der MakePwd-Passwortstärke. Sie öffnet sich ohne Registrierung und ohne Passworttresor. Laut Produkttext wird das geprüfte Passwort nicht hochgeladen und nicht in Analytics geschrieben. Der Abgleich läuft gegen eine öffentliche Häufigkeitsliste, die in diesen Tab geladen wird. Das ist nicht Have I Been Pwned und kein netzweiter Stuffing-Check. Ein Treffer setzt die Stufe auf schwach. Über 128 Zeichen macht die Umsetzung nur noch den exakten Vergleich und überspringt angehängte Ziffern und Leetspeak.

Üben Sie mit einer wegwerfbaren Testkette, nicht mit einem lebenden Passwort. Lassen Sie Network offen: Sie sollten die Listendatei und vielleicht Analytics sehen, nicht den vollen Text aus dem Eingabefeld. Brauchen Sie ein neues Passwort, ist der Generator ebenfalls sofort nutzbar. Der Zufallsmodus umfasst 6–128 Zeichen, Standard 16; unter 8 Zeichen erscheint ein Hinweis, dass die Sicherheit geringer ist. Erzeugen und Prüfen laufen im Browser. Klartext bleibt standardmäßig auf diesem Gerät.

Der Sinn der Übung ist nicht zu beweisen, dass irgendeine Site „am vollständigsten sucht“. Er ist, dass Sie Kolleginnen und Kollegen drei Sätze sagen können: Ich habe die Listenzeilen gezählt; ich habe in Network nach einem Canary gesucht; bei keinem Treffer habe ich nur „nicht in dieser Liste“ geschrieben. Auf jeder anderen Seite, die eine „lokale Prüfung schwacher Passwörter“ behauptet, gelten dieselben Schritte.

Drei Dinge für das nächste Prüfergebnis

Erstens: Treffer heißt wechseln; kein Treffer schließt nur die aktuelle Liste aus – lesen Sie das nicht als nie geleakt. Zweitens: kurze lokale Liste, HIBP-Hashpräfix mit fünf Zeichen und volles Offline-Korpus sind drei Datenwege; die Bedeutung eines Fehlschlags folgt dem Weg. Drittens: Entropie und Liste nicht gegeneinander aufrechnen – ein kurzes Passwort kann fehlen, ein langes, aber gängiges kann treffen.

Wenn die nächste Frage lautet, ob Klartext diesen Tab als Geschäftsdaten verlassen hat, lesen Sie Im Browser verschlüsseln: so prüfen Sie, dass Klartext das Gerät nicht verlassen hat. Dieser Text macht aus „was deckt die Liste schwacher Passwörter ab?“ einen Satz, den Sie aufschreiben können.