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

„Prüfen, ob dieses Passwort geleakt ist“ wird oft wie eine einzige Aufgabe behandelt. Es sind mindestens drei: den Klartext an eine Website geben, ein Hash-Präfix an Have I Been Pwned senden oder in diesem Tab eine öffentliche Häufigkeitsliste abgleichen. Entscheidend ist nicht das Wort „lokal“ auf der Seite, sondern welche der drei Varianten die Anfrage tatsächlich ausgeführt hat – und welchen Satz ein Treffer oder Nichttreffer in einem Ticket tragen kann.

Zuerst das Fazit: Eine lokale Liste schwacher Passwörter trägt nur eine enge Aussage – „sieht diese Zeichenfolge aus wie ein bereits weit missbrauchtes Passwort“. Ein Nichttreffer beweist nicht, dass sie nie in einem Dump stand. Ein Treffer heißt nur: zu häufig, sofort ersetzen. Die Passwort-Bereichsabfrage von Have I Been Pwned ist ein anderes Protokoll: Sie sendet die ersten fünf Zeichen eines SHA-1-Hashs. Bevor Sie Klartext in irgendein „Online-Prüffeld“ einfügen, klären Sie, welche der drei Varianten Sie gerade starten.

Die Suchintention in einem Satz beantworten

Eine lokale Liste geleakter Passwörter kann nur eines beweisen: Die eingegebene Zeichenfolge lässt sich gegen die öffentliche Häufigkeitsliste, die bereits in diesem Tab liegt, zuordnen – oder eben nicht. Sie beweist nicht „im Netz nie gesehen“ und beantwortet nicht „ist meine E-Mail in einem Leak“. Die Pwned-Passwords-Bereichsabfrage von Have I Been Pwned (HIBP) ist ein eigener Weg: Dieses Gerät berechnet SHA-1 und sendet nur die ersten fünf Hex-Zeichen an https://api.pwnedpasswords.com/range/{prefix}; das restliche Suffix wird auf dem Client verglichen.

Dieser Artikel richtet sich an Entwicklung und Betrieb, die ein altes Passwort „nur kurz prüfen“ wollen, und an Support, dem ein Kollege einen Link zu einem „Online-Passwort-Checker“ geschickt hat. Er ersetzt nicht die Bedienung von Passwortstärke prüfen und wiederholt nicht den Network-Durchgang zu „hat lokale Verschlüsselung Klartext hochgeladen“. Mitnehmen sollten Sie: Was jede Methode von diesem Gerät wegschickt, wie weit die Varianten einer lokalen Liste reichen und welchen Satz ein Treffer oder Nichttreffer wirklich ins Ticket darf.

Drei „Leak-Checks“ sind nicht dieselbe Aufgabe

Suchen Sie „Passwort geleakt prüfen“, mischen die Treffer Protokolle, die nichts miteinander zu tun haben. Manche Seiten POSTen, was im Feld steht. Manche rufen die k-anonyme Bereichs-API von HIBP auf. Manche laden eine kurze Wortliste und suchen im Browser. Alle drei können „nicht gefunden“ oder „geleakt“ auf dasselbe Abzeichen malen. Die Anfragezeile ist eine andere – und damit auch die Aussage, die Sie verteidigen können.

Das OWASP Authentication Cheat Sheet verlangt in Registrierung und Passwortwechsel, gängige und kompromittierte Passwörter zu blockieren, und nennt sowohl Pwned Passwords als auch öffentliche Listen wie SecLists. Es setzt eine lokale Liste mit rund 800 Zeilen und einen Korpus mit Milliarden Hashs nicht gleich. Steht im Ticket nur „geprüft, nicht geleakt“, weiß die nächste Leserin nicht, welches Netz Sie genutzt haben.

Methode Was dieses Gerät verlässt Was ein Nichttreffer tragen kann
Klartext oder vollständigen Hash hochladen Das Passwort selbst oder ein Digest, der zum Vergleich oder zur Wiederherstellung reicht Nur: Diese Site hat diesmal nicht markiert – nicht: Es ist sicher
HIBP-Bereichsabfrage Die ersten 5 Hex-Zeichen eines SHA-1- oder NTLM-Hashs Dieser Hash steht nicht im aktuellen HIBP-Index
Lokale öffentliche Häufigkeitsliste Die Listendatei selbst; das geprüfte Passwort bleibt im Tab Diese kurze Liste und ihre Variantregeln haben nicht getroffen

Die dritte Methode nutzt trotzdem das Netz: Der Browser holt die Listendatei per GET. Die Datei ist eine öffentliche Wortliste, nicht Ihr Passwort. Jede Anfrage als „es ging online, also wurde das Passwort hochgeladen“ zu lesen, verfehlt die Grenze. Das Wort „lokal“ auf der Seite als Beweis zu nehmen, übersieht die erste Art von Site.

Experimentieren Sie nicht mit einem Produktions-Tresor-Passwort, einem unrotierten API-Token oder einer Online-Banking-PIN. Erfinden Sie einen Canary, der nur für diese Prüfung existiert – etwa CanaryPwd-20260902-xK9. Sie prüfen, ob diese Anfrage diese Zeichenfolge mitgenommen hat – Sie sollen kein echtes Geheimnis ein zweites Mal preisgeben.

Wogegen die lokale Liste tatsächlich abgleicht

Auf der Seite Passwortstärke prüfen von FastPwd kommt die Liste vom gleichen Origin-Pfad data/leaked-top10k.txt und wird in diesem Tab zu einer Tabelle aus Kleinbuchstaben-Schlüssel und Rang aufgebaut. Der Dateiname sagt top10k, weil öffentliche Häufigkeitslisten oft so heißen. Öffnen Sie die Antwort: Sie zählen knapp über 800 nichtleere Zeilen; sie beginnen mit 123456, password, qwerty – Zeichenfolgen, die Dump um Dump auftauchen. Die Produkttexte nennen diese Datei weder „10.000 Einträge“ noch „jeden Leak im Netz“.

Die Suche ist kein einzelner Gleichheitstest. Die Umsetzung läuft in vier Stufen. Ein Treffer in einer Stufe färbt das Passwort rot und erzwingt die Stufe Schwach.

  1. Exakter Vergleich: Die Eingabe entspricht einem Listeneintrag.
  2. Kleinschreibung: Zuerst in Kleinbuchstaben, damit Password und password derselbe Eintrag sind.
  3. Endziffer 0–999 abstreifen: qwerty123 wird zu qwerty und dann gesucht.
  4. Gängiges Leet: @/4→a, 3→e, 1/!→i, 0→o, 5/$→s, 7→t. Dieselbe Stufe kann nach dem Abstreifen der Endziffern laufen.

Ist die Eingabe länger als 128 Zeichen, entfallen die letzten beiden Stufen – nur exakter und kleingeschriebener Vergleich. Schlägt das Laden der Datei fehl, fällt die Seite auf eine eingebaute Mindestmenge zurück: password, 123456, 12345678, qwerty, admin123; die Statuszeile sagt weiter, dass die Prüfung auf diesem Gerät fertig wurde. Der Rang dient nur dem Hinweis: Top 100, Top 500, Top 1.000 oder der Rückfall „öffentliche Leak-Liste“. Das ist nicht der HIBP-Zähler „N-mal gesehen“.

NIST SP 800-63B-4 verlangt vom Prüfer bei Kontoeröffnung und Passwortwechsel, den Kandidaten als ganze Zeichenfolge gegen eine Sperrliste gängiger, erwartbarer oder kompromittierter Passwörter zu halten – nicht als Teilstring – und keine zweite Komplexitätsregel darüberzulegen. Eine lokale Häufigkeitsliste deckt die Schicht „zuerst die raten, die Angreifer zuerst versuchen“. Die Datei ist weit kleiner als die Wörterbücher, mit denen Angreifer sprühen, und weit kleiner als die Leak-Hashs, die HIBP laufend einmischt. Im Juni 2026 hat allein der Bestand June 2026 Stealer Logs rund 124 Millionen eindeutige Passwörter ergänzt. Knapp über 800 öffentliche Häufigkeitswörter fangen 123456. Sie fangen keine lange Passphrase, die nur in einem internen Dump vorkam.

Was eine HIBP-Bereichsabfrage sendet – und was nicht

HIBP schreibt auf der eigenen Passwortseite: Ein Nichttreffer „heißt nicht unbedingt, dass es ein gutes Passwort ist, nur dass es in den Daten dieser Site nicht vorkommt.“ Das Protokoll steht in API v3 · Pwned Passwords. Der Client hasht das Passwort mit SHA-1 (oder NTLM bei mode=ntlm), nimmt die ersten fünf Hex-Zeichen und fordert GET https://api.pwnedpasswords.com/range/{prefix}. Der Server gibt jedes Suffix unter diesem Präfix plus einen Seen-Count zurück. Die restlichen 35 Zeichen des 40-Zeichen-Hashs bleiben auf diesem Gerät zum Vergleich.

Die veröffentlichte Größenordnung können Sie vor Ort nachprüfen: Eine Bereichsabfrage liefert üblicherweise rund 800 Suffixe; der Präfixraum hat 165 = 1.048.576 Werte, von 00000 bis FFFFF, und jedes Präfix soll HTTP 200 liefern – nicht 404. Ein optionaler Header Add-Padding: true polstert die Antwort auf 800–1.000 Zeilen, damit niemand das Präfix aus der Antwortlänge ableitet. Cloudflare nennt das in Validating Leaked Passwords with k-Anonymity eine k-anonyme Bereichsabfrage: Der Server erhält nie den vollständigen Hash eines Passworts, das noch nicht im Korpus steht, und kann diese eine Abfrage später nicht allein „entlarven“.

Eine E-Mail-Abfrage ist ein anderer Weg. Die Dokumentation ist eindeutig: Steht eine E-Mail-Adresse im Pfad, geht diese Adresse an HIBP. Die k-anonyme E-Mail-Suche sendet die ersten sechs Zeichen des SHA-1 der Adresse – nicht die ersten fünf eines Passwort-Hashs. Steht im Ticket „ich habe HIBP geprüft“, schreiben Sie, ob Sie ein Passwort-Hash-Präfix oder eine E-Mail abgefragt haben. Die Datenschutzgrenze ist eine andere – und der Schluss auch.

FastPwd ruft keine der beiden HIBP-Schnittstellen auf. Passwortstärke prüfen kann eine lokale Entropieschätzung plus diese öffentliche Häufigkeitsliste. Brauchen Sie einen Korpus in Milliardengröße, nutzen Sie die offizielle HIBP-Seite oder eine Offline-Kopie, die Sie selbst hosten, und öffnen Sie Network selbst: In der Anfragezeile dürfen nur fünf Hex-Zeichen stehen. Gehen Sie nicht davon aus, „ein Sicherheitstool fragt HIBP für Sie ab“.

Mit Network prüfen, dass das Passwort nicht rausgegangen ist

„Nicht hochgeladen“ auf der Seite ist kein Beweis. Eine Canary-Zeichenfolge ist einer. Die Schritte gehören zur selben Familie wie „hat lokale Verschlüsselung Klartext mitgenommen“ – beobachtet werden das Passwortfeld und die Listendatei.

  1. Öffnen Sie DevTools Network und aktivieren Sie Preserve log. Lassen Sie den Filter zuerst leer, damit Statistikmeldungen nicht verschwinden.
  2. Geben Sie auf Passwortstärke prüfen einen Canary ein, etwa CanaryPwd-20260902-xK9, und warten Sie, bis die lokale Berechnung fertig ist – rund 280 Millisekunden nach dem letzten Tastendruck.
  3. Suchen Sie in der Anfrageliste nach diesem Canary. Er darf weder in der Anfragezeile noch in Query, Body oder Formularfeld stehen.
  4. Sie sollten ein same-origin GET auf data/leaked-top10k.txt sehen. Öffnen Sie die Antwort: ein öffentliches Passwort pro Zeile, Ihr Canary nicht darunter.
  5. Behauptet eine Site, mit HIBP zu sprechen, suchen Sie api.pwnedpasswords.com/range/: Im Pfad stehen fünf Hex-Zeichen, kein Klartext.

Zugriffsstatistik darf trotzdem existieren. Die Audit-Ereignisse von FastPwd schicken nur Namen – etwa „Prüfung gestartet“, „Ergebnis schwach“ oder „Treffer in Leak-Liste“ – und senden den Inhalt des Eingabefelds nicht als Parameter. Öffnen Sie eine Meldung an /tj/matomo.php und suchen Sie den Canary; er darf nicht treffen. Das Schließen des Tabs hinterlässt diese Eingabe nicht auf einem FastPwd-Server – wenn sie nie als Fachdaten angekommen ist. Dieser Satz muss auf der Suche beruhen, die Sie gerade ausgeführt haben, nicht auf „ich habe die Seite geschlossen“.

Erscheint der Canary in irgendeiner Anfrage, dreht sich der Schluss. Egal, was auf dem Knopf stand – „lokal“, „privat“, „im Browser“: Diese Prüfung hat das Passwort bereits aus dem Tab geschickt. Wechseln Sie das Tool oder eine Offline-Liste und wiederholen Sie dieselben Schritte.

Was ein Treffer tragen kann – und ein Nichttreffer nicht

Bei einem Treffer gehört dieser Satz ins Ticket: „Diese Zeichenfolge hat die mit der Seite geladene öffentliche Häufigkeitsliste getroffen (exakt / Groß-Klein / Endziffern / Leet). Auf diesem Gerät gilt sie als extrem häufiges schwaches Passwort. Ersetzen, und auf anderen Sites nicht wiederverwenden.“ Nicht ins Ticket gehört: „Der Server der Gegenseite hat bestätigt, dass das der Klartext aus Leak X im Jahr Y ist.“ Die lokale Liste hat keinen Vorfallnamen und keinen Seen-Count – nur einen Ranghinweis.

Bei einem Nichttreffer ist der tragfähige Satz kürzer: „Kein Treffer gegen die aktuelle öffentliche Häufigkeitsliste und ihre vier Variantstufen.“ Sie dürfen nicht schreiben „nie geleakt“, „weiterverwenden“ oder „sauberer als HIBP“. Eine Liste mit knapp über 800 Häufigkeitswörtern war nie dazu da, Sicherheit zu beweisen. Spray-Wörterbücher von Angreifern, historische Firmenpasswörter und eine lange Phrase aus einem privaten Dump stehen auf dieser Seite nicht.

Entropie ist ein drittes, paralleles Signal. Die Seite schätzt Bits aus Länge und Zeichenklasse: ≥ 80 ist Sehr stark, ≥ 60 ist Stark, ≥ 40 ist Mittel, der Rest ist Schwach. Offline-Brute-Force wird mit rund 10 Milliarden Versuchen pro Sekunde gezeigt; ein online, ratenbegrenzter Versuch mit rund 1.000 pro Sekunde. Diese Zahlen vergleichen relative Kosten. Sie sind kein Countdown. Unter 8 Zeichen oder ein Treffer in der eingebauten Top-Menge gängiger schwacher Passwörter erzwingt Schwach. Ein Treffer in der öffentlichen Liste schreibt die Stufe auf Schwach um, selbst wenn die Entropie hoch ist – weil ein Wörterbuchangriff nicht den Weg „mittlerer Brute-Force“ geht.

FAQ

Heißt ein Nichttreffer in der Liste schwacher Passwörter, dass das Passwort nie geleakt wurde?

Nein. Ein Nichttreffer heißt nur: In der öffentlichen Häufigkeitsliste dieses Tabs haben exakter Vergleich, Kleinschreibung, das Abstreifen einer Endziffer 0–999 und gängiges Leet nicht gegriffen. Das beweist nicht, dass die Zeichenfolge nie in einem Dump stand, nie bei Have I Been Pwned vorkam oder weiterverwendet werden darf.

Sendet eine Have-I-Been-Pwned-Passwortprüfung den Klartext?

Nicht, wenn der Client die offizielle API einhält. Eine Pwned-Passwords-Bereichsabfrage nimmt nur die ersten fünf Zeichen eines SHA-1- oder NTLM-Hashs und gibt rund 800 Suffixe zurück; der vollständige Vergleich bleibt auf dem Client. Klartext und vollständiger Hash dürfen in der Anfrage nicht stehen. Eine E-Mail-Prüfung ist eine andere Schnittstelle: Steht die Adresse im Pfad, geht sie an den Dienst. Vertrauen Sie der Anfragezeile, die Sie in Network geöffnet haben – nicht der Knopfbeschriftung.

Fragt FastPwd Passwortstärke prüfen Have I Been Pwned ab?

Nein. Abgeglichen wird die öffentliche Häufigkeitsliste, die mit der Seite heruntergeladen wird. Das geprüfte Passwort geht nicht als HTTP-Fachdaten raus und landet nicht in der Zugriffsstatistik. Die Statistik speichert nur Ereignisnamen wie „Prüfung gestartet“ oder „Ergebnis schwach / mittel / stark“. Sofort nutzbar, kein Konto, und auf der Site gibt es keinen Passwort-Tresor, in dem ein Prüfungsprotokoll liegen könnte.

Ist ein Passwort trotzdem stark, wenn die Entropie hoch ist, die Liste aber trifft?

Auf diesem Gerät erzwingt ein Treffer in der öffentlichen Liste schwacher Passwörter die Stufe Schwach. Entropie schätzt die Brute-Force-Kosten über einen Zeichenraum. Die Liste beantwortet, ob diese Zeichenfolge bereits in einem Angreiferwörterbuch steht. Beide Fragen heben einander nicht auf. NIST SP 800-63B-4 verlangt vom Prüfer den Abgleich einer ganzen Zeichenfolge gegen eine Sperrliste gängiger oder kompromittierter Passwörter – nicht Komplexitätsregeln oder einen Kalenderhinweis zum Wechseln.

Die Schritte mit einem Testpasswort zu Ende führen

Wenn Sie eine Seite mit klar beschriebener Rechengrenze üben wollen, öffnen Sie Passwortstärke prüfen von FastPwd. Sofort nutzbar – keine Registrierung. Tippen Sie zuerst password oder qwerty123: Sie sollten einen Treffer in der öffentlichen Liste sehen, erzwungen auf Schwach. Tippen Sie dann den Canary oben: Er sollte die Liste verfehlen, und eine Network-Suche sollte diese Zeichenfolge nicht finden. Sie können das Listen-GET öffnen und die Zeilen zählen; sie sollten zu „knapp über 800 Häufigkeitswörter“ in diesem Artikel passen.

Nach der Stufe Schwach öffnen Sie den Passwort-Generator und ziehen auf diesem Gerät eine neue Zeichenfolge: Der Zufallsmodus hat 6–128 Zeichen, Standard 16; unter 8 Zeichen gilt als schwächer. Müssen Sie das neue Passwort einem Kollegen übergeben, wechseln Sie zu Burn-Link: Dieses Gerät verschlüsselt mit AES-256-GCM, der Server speichert nur Chiffretext, der Schlüssel sitzt hinter der Raute im Link. Fügen Sie einen vollständigen Burn-Link nicht zurück in irgendein „Online-Prüffeld“.

Der Sinn der Übung ist nicht, irgendeine Site als „absolut sicher“ zu beweisen. Sie sollen vor dem Klick auf Prüfen einen Vergleich haben, den Sie einem Kollegen zeigen können: Dieser Lauf hat Klartext hochgeladen, ein Hash-Präfix gesendet oder eine kurze lokale Liste genutzt; bei Treffer ersetzen; bei Nichttreffer nicht „nie geleakt“ schreiben. Dieselben Schritte gelten für jede Erweiterung mit „Sicherheitsnote“ oder „Leak-Abfrage“.

Wenn das nächste Mal jemand ein Passwort in ein Prüffeld einfügt, stellen Sie drei Fragen. Erstens: Hat die Anfrage Klartext oder einen vollständigen Hash getragen? Zweitens: Wurde gegen rund 800 Häufigkeitswörter abgeglichen oder eine Bereichsabfrage im HIBP-Stil ausgeführt? Drittens: Welchen Satz soll das Ticket bei Nichttreffer tragen? Nur eine Prüfung, die Sie wiederholen können, gehört in Ihre eigene Passwortrichtlinie.

Weiterlesen

Ob die Prüseite selbst die Originalzeichenfolge rausgeschickt hat, prüfen Sie mit demselben Canary in einem vollständigeren Network-Durchgang: So prüfen Sie, dass browserlokale Verschlüsselung keinen Klartext sendet. Müssen Sie ein vollständiges Geheimnis einem Menschen übergeben – nicht einem Prüffeld –, steht dort, warum der Schlüssel hinter der Raute sitzen kann und wann diese Schicht fällt: Warum sich ein Schlüssel hinter der URL-Raute eignet – und wann der Schutz fällt. Bevor Tickets und Logs in ein KI-Feld wandern, Felder an der Quelle vergleichen: Bevor Sie Tickets und Logs in eine KI einfügen: Welche Felder dieses Gerät verlassen.