Lokale Sperrliste und Have I Been Pwned: was jede Prüfung beweist

Vor dem Jobwechsel, vor einem neuen Dienst, bevor aus dem alten Passwort «noch ein Ausrufezeichen» wird, suchen viele erst: Steht diese Zeichenkette schon in einem Datenleck? In den Treffern sitzen «Passwortstärke prüfen», «Have I Been Pwned» und «Online-Leak-Check» nebeneinander und klingen wie dieselbe Antwort. Öffnest du die Seiten, zerfallen die Protokolle: Die eine POSTet das Eingabefeld an den eigenen Host, die nächste holt bei einem Dritten eine Liste von Hash-Suffixen, die dritte lädt eine öffentliche Wortliste schwacher Passwörter und vergleicht im Tab. Auf die Frage «hat das Passwort diese Seite verlassen?» geben die drei Abläufe drei verschiedene Antworten.

Dieser Text wiederholt nicht, wie ein Balken Schwach / Mittel / Stark anzeigt, und er erklärt nicht, wie man fremde Datenbanken angreift. Die Frage ist enger: Was eine lokale Sperrliste beweisen kann — und was eine Abfrage gegen ein großes Leak-Korpus beweisen kann, wenn sie ehrlich gebaut ist. Die Passwortstärke-Prüfung von MyPassGen gehört zur ersten Sorte: Das Testpasswort wird nicht hochgeladen; die Seite gleicht gegen eine öffentliche Liste schwacher Passwörter ab, die mit der Seite geladen wird; jedes Tool öffnet ohne Konto. Unten liegt die Grenze offen, danach prüfst du sie im Network-Panel der Entwicklertools.

Drei verschiedene «Passwort-Checks»

Zuerst die Protokolle benennen. In deutschsprachigen Texten heißt oft beides «Sperrliste»: die kurze Wortliste im Browser und die HIBP-Abfrage per k-Anonymität. Marketing kann «lokal», «kein Upload» und «gegen Leaks geprüft» in denselben Satz packen und trotzdem drei Designs meinen.

Die erste Methode ist am bequemsten und am schwersten zu prüfen. Eine Seite kann versprechen, die Anfrage «sofort zu löschen». Logs, Backups und Analytics-Skripte können trotzdem eine Kopie behalten. Die zweite ist das Verfahren, das Have I Been Pwned für Pwned Passwords dokumentiert: Der Browser hasht zuerst, schickt nur das Präfix an api.pwnedpasswords.com/range/{prefix} und gleicht die Suffixe lokal ab. Die dritte schickt nicht einmal ein Präfix. Die Wortliste ist ein öffentlicher Satz häufiger schwacher Passwörter — meist Hunderte bis zehntausend Zeilen, nicht «jeder Dump im Netz».

Das U.S. National Institute of Standards and Technology schreibt in NIST SP 800-63B-4, Verifier sollen ein neues oder geändertes Passwort gegen eine Liste «häufig genutzter, erwartbarer oder kompromittierter» Werte prüfen — und keine Pflichtregeln für Groß-/Kleinbuchstaben, Ziffern und Sonderzeichen obendrauf stapeln. Die Sperrliste soll vor allem die Treffer blockieren, die ein Online-Angreifer zuerst ausprobiert; ist die Liste größer als das Rate-Limit-Fenster, bringen Extra-Zeilen wenig. Genau dort sitzt eine lokale Top-Liste: ein erstes Sieb für alltägliche schwache Passwörter, keine Suche in jeder Leak-Datei.

Was es heißt, den Klartext an eine Website zu geben

Eine Reihe «Online-Passwort-Checker» legt die Zeichenkette aus dem Eingabefeld weiter in den Request-Body. Manche nennen das JSON-Feld password. Manche hängen sie in den Query-String. Manche kodieren umkehrbar und POSTen das. Für den Browser sieht der Traffic aus wie ein Login-Formular: Gegenhost, Reverse-Proxy und Access-Log können diese Übermittlung alle lesen.

HTTPS stoppt Mithörer auf dem Weg. Es hindert das andere Ende nicht, Klartext auf die Platte zu schreiben, und es hindert kein Analytics-Skript, das Feld weiterzureichen. Was du verringern willst, ist ob diese eine Prüfung eine weitere Partei erzeugt hat, die die Zeichenkette jetzt kennt. Das ist nicht die Aufgabe von HTTPS. Der vorherige Text, wie du prüfst, dass Browser-Verschlüsselung keinen Klartext hochlädt, nutzt dieselbe Regel: Slogans beweisen nichts; Traffic schon.

Es gibt einen leiseren Weg, es herauszugeben: das Testpasswort in einen Query-Parameter schreiben und die URL an Kolleginnen weiterleiten oder ins Ticket werfen. Query-Strings stehen in der Request-Zeile und im Log der Gegenseite. Manche Drittanbieter-Ressourcen bekommen Pfad und Query noch im Referer. Ist die Zeichenkette ein lebendes Kontopasswort, verbreitest du es selbst. Der sichere Default: Ein echtes Passwort bleibt im Eingabefeld des aktuellen Tabs. Schreib es nicht in eine URL, und füge es nicht in einen «Checker» ein, der das Original hochlädt.

Die Vollabfrage, die nur ein Hash-Präfix schickt

Die Range-API von Have I Been Pwned trennt «ein großes Korpus durchsuchen» von «das Original übergeben». Dokumentiert ist: Passwort als UTF-8 kodieren, SHA-1 rechnen (NTLM wird ebenfalls angeboten), die ersten fünf Hex-Zeichen nehmen, GET https://api.pwnedpasswords.com/range/{prefix} anfragen. Die Antwort ist eine Liste von Suffixen und Häufigkeiten, getrennt durch Doppelpunkt. Der Client setzt Präfix und Suffix auf dem Gerät wieder zusammen und sucht einen vollständigen Treffer. Troy Hunt nennt das k-Anonymität in Understanding Have I Been Pwned's Use of SHA-1 and k-Anonymity: Der Server sieht einen Hash-Eimer, nicht den vollen Hash und nicht das Passwort.

Als Cloudflare das Verfahren mit HIBP veröffentlichte, standen Zahlen darin, die du am Text noch gegenprüfen kannst: Bei einem 5-Zeichen-Präfix lag der Median je Eimer bei etwa 305 Hashes, die mediane Antwort bei etwa 12,2 KB. Die API bietet außerdem Add-Padding: true: Jede Antwort wird auf grob 800–1000 Zeilen aufgefüllt, damit ein Beobachter nicht allein an der Länge erkennt, «das war ein sehr häufiges Passwort». All das macht eine Bereichsabfrage viel zurückhaltender als ein Klartext-POST — und es bleibt ein ausgehender Request. Im Network erscheint ein Aufruf an api.pwnedpasswords.com. Trenn das Netz, und diese Sorte Abfrage muss scheitern.

Eine Bereichsabfrage ist auch keine «perfekte Anonymität». Das Präfix verrät einem Beobachter, in welchen der 16⁵ Eimer dein Hash fiel. Kopiert Seitenskript das Original, bevor es das Präfix schickt, hilft k-Anonymität nicht. E-Mail-Suche und Passwort-Suche sind außerdem nicht dieselbe API: HIBP v3 nutzt für gehashte E-Mail-Bereichsabfragen ein 6-Zeichen-Präfix, und das ist eine andere Produktfläche. Dieser Text vergleicht nur «steht dieses Passwort in einem Passwort-Korpus». Mailbox-Abos und Domain-Monitoring sind nicht dieselbe Prüfung.

Deshalb ist «wir nutzen HIBP» nicht derselbe Satz wie «das Passwort hat das Gerät nie verlassen». Genau ist: Original und voller Hash gehen nach Design nicht raus; ein Präfix und ein Range-Request schon. Akzeptierst du «eine Drittpartei, die das Korpus pflegt, erfährt den Hash-Eimer», ist das ein vernünftiger Engineering-Kompromiss. Verlangst du «diese Prüfung darf nicht einmal ein Präfix senden», nimm die lokale Liste im nächsten Abschnitt — und akzeptiere eine deutlich schmalere Abdeckung.

Die lokale Sperrliste lädt nur die Wortliste

Ein lokaler Abgleich läuft umgekehrt: eine öffentliche Liste schwacher Passwörter an den aktuellen Origin laden, dann im Skript eine Mengenprüfung. Im Network darf die Wortliste auftauchen. Das Testpasswort aus dem Eingabefeld darf dort nicht stehen. Die Liste selbst ist öffentliche Daten. Eine typische Quelle ist eine «Top-N aus zehn Millionen Passwörtern»-Datei in SecLists, rund um die Sammlung von OWASP / Daniel Miessler. Sie beantwortet «würde das erste Angreifer-Wörterbuch das versuchen», nicht «liegt das in irgendeinem unveröffentlichten Dump».

Die Passwortstärke-Prüfung von MyPassGen folgt dieser Grenze. Nach dem Öffnen der Seite kommt data/leaked-top10k.txt: rund 860 Zeilen, ein kleingeschriebenes Passwort je Zeile, beginnend mit Ketten wie 123456, password und qwerty. Der Abgleich läuft im Browser: zuerst Kleinbuchstaben, dann eine kurze Menge Varianten — @ / 4 als a, 0 als o und ähnliches gängiges Leetspeak, plus ein bis drei Ziffern am Ende streichen — dann die Menge testen. Ein Treffer gilt als Schwach, auch wenn die Kette «lang» wirkt. Lädt die Wortliste nicht, fällt das Skript auf einen winzigen eingebauten Satz zurück (password, 123456 und wenige andere). Es wechselt nicht zu einer externen Leak-API.

Der Stärkebalken ist eine zweite lokale Rechnung. Der Zeichenpool addiert 26 + 26 + 10 + 32, je nachdem ob Klein-, Großbuchstaben, Ziffern und Symbole vorkommen. Die Entropie ist grob Länge mal log2(Pool), dann ein Abschlag bei zu vielen Wiederholungen. Die Schwellen: unter etwa 40 Bit Schwach, unter 60 Mittel, unter 80 Stark, ab 80 Sehr stark. Unter 8 Zeichen gibt es einen eigenen «zu kurz»-Hinweis. Der Zufallsgenerator erlaubt 6–128 Zeichen und startet bei 16. Offline-Brute-Force wird mit 10¹⁰ Versuchen pro Sekunde geschätzt, Online mit Rate-Limit mit 10³ — Größenordnungen zum Lesen, kein Versprechen für eine bestimmte GPU. Analytics-Events merken die Stufe und ob die Liste traf. Sie schicken das Passwort nicht mit.

Diese Zahlen kannst du auf diesem Gerät gegenprüfen: Wortlistenzeilen im Editor oder mit wc -l zählen. Im Network soll die Wortliste stehen, die Eingabe nicht. Das darfst du trotzdem nicht als «wir haben das ganze Netz durchsucht» schreiben. Rund 860 Zeilen decken nicht einmal die öffentliche Top 10.000 aus SecLists, geschweige denn ein hash-indexiertes Korpus in der Größe von HIBP. Die einzige ehrliche Folgerung aus einem Nicht-Treffer: Es ist kein häufiges schwaches Passwort auf dieser Liste.

Der Stärkebalken beweist kein Datenleck

Ein Stärkebalken schätzt den Suchraum. Er durchsucht kein Archiv. Ein 20-stelliges Zufallspasswort kann hohe Entropie haben und trotzdem schon in fremden Leak-Dateien stehen. Angreifer laufen das Alphabet nicht von vorn durch; sie nehmen die fertige Liste. Umgekehrt erfüllt Password1! oft ein Formular «Groß, Klein, Ziffer, Sonderzeichen» und steht fast immer auf einer öffentlichen Wortliste schwacher Passwörter. Genau dieses Ausweichmuster ist der Grund, warum NIST die Kompositionsregeln gestrichen hat.

Zeigt eine Prüfseite Stufe und Listenergebnis, soll die Liste den Balken überschreiben: Ein Treffer ist Schwach. Der Balken bleibt nützlich. Er markiert «zu kurz», «nur eine Zeichenklasse» oder eine qwerty-Tastaturfolge. Allein kann er kein «darfst du weiterverwenden»-Zertifikat ausstellen. Die Entscheidung, die du meist brauchst, sind zwei Sätze: Treffer auf der Liste oder kürzer als 8 — jetzt ändern; kein Treffer und lang genug — trotzdem nicht über Dienste wiederverwenden, und für wichtige Konten eine frische Zeichenkette mit einem Passwortmanager oder dem lokalen Generator schreiben.

«Die Netz-Abfrage hat keinen Treffer gemeldet» ist auch kein Ende. Eine Bereichsabfrage hängt davon ab, was das andere Korpus aufgenommen hat und wie oft es aktualisiert. Unveröffentlichte Leaks, interne Systempasswörter und Varianten, die dort noch nicht gehasht sind, tauchen nicht auf. Das ist weit breiter als eine lokale Liste mit 860 Zeilen — und trotzdem die Stichprobe einer anderen Partei. Beide Tools hintereinander zu nutzen ist in Ordnung, wenn du unterscheiden kannst, was jeweils rausgegangen ist und was ein Fehlschlag bedeutet.

Network sofort prüfen: Wortliste darf, Passwort nicht

Die Schritte unten hängen nicht an einem Markenversprechen. Nimm ein wegwerfbares Testpasswort — password oder eine temporäre Kette, die du auf keinem Konto genutzt hast. Klebe kein lebendes Passwort in eine Demo.

1. Öffne in den Entwicklertools Network und schalte Preserve log ein. Filter zuerst Fetch / XHR, dann Dokumente und übrige Requests.
2. Lade die Prüfseite neu. Du solltest eine statische Liste sehen (auf dieser Site leaked-top10k.txt). Öffne den Request: Die Antwort ist ein Passwort je Zeile, der Request-Body soll leer sein.
3. Tippe das Testpasswort ins Feld und warte auf ein Ergebnis. Prüfe neue Requests: URL, Query, JSON und Formularfelder dürfen die gerade getippte Zeichenkette nicht enthalten.
4. Suche im Panel nach pwnedpasswords, hibp und range/. Ein lokales Listen-Design darf diese Hosts nicht treffen. Tut es das, lief eine Bereichsabfrage — lies den vorigen Abschnitt statt «vollständig lokal».
5. Scanne Analytics-Requests (Pfade enthalten oft matomo oder collect). Eventnamen dürfen Schwach / Mittel / Stark sagen. Werte dürfen das Passwort nicht enthalten.
6. Zum Vergleich einer Vollkorpus-Variante dieselbe Wegwerfkette auf einer Seite, die HIBP aufruft: Du solltest ein GET an api.pwnedpasswords.com/range/ sehen, dessen Pfad fünf Hex-Zeichen trägt und sonst nichts.

Netz trennen und noch einmal tippen. Das ist ein nützlicher Extra-Check für ein lokales Design: Ist die Wortliste schon im Cache, sollen Stärke und Listentreffer weiter rechnen; eine Bereichsabfrage soll scheitern. Behandle «null Requests» nicht als einzige Bestehensgrenze — der erste Besuch muss die Wortliste holen, und das ist nicht derselbe Traffic wie ein Passwort-POST. Der vorherige Text hat dasselbe Panel für lokale Verschlüsselung genutzt. Hier beobachtest du eine Extra-Sache: ob irgendein fachlicher Request deine Eingabe trägt.

Irrtümer: grüner Balken, «das ganze Netz», «schon geprüft»

«Der Balken ist grün, also nicht geleakt» hält nicht. Grün beschreibt den Zeichenraum. Ein Leck beschreibt, ob jemand anderes dieselbe Zeichenkette schon hat. Beides kann gleichzeitig wahr sein.

«Da steht lokale Berechnung, also hat nichts den Tab verlassen» hält auch nicht. Eine lokale Liste lädt eine Wortliste. Eine Bereichsabfrage lädt einen Hash-Eimer. Verbieten willst du, dass Original — und der volle Hash — als Fachdaten rausgehen. Du musst nicht jeden HTTP-Request verbieten.

«Es stand nicht in HIBP, also darf ich es auf jeder Website wiederverwenden» ist der teure Irrtum. Credential Stuffing probiert ein Passwort gegen viele Dienste. Es verlangt nicht, dass dieses Passwort in den öffentlichen Top-Tausend steht. Weder lokale Liste noch Vollkorpus-Abfrage heilen Wiederverwendung. Erzeuge ein neues Passwort auf diesem Gerät, nimm den Zufallsdefault von 16 Zeichen oder länger, und hinterlege je Dienst eine andere Kette.

Ein Passwort in den Chat kleben, damit Kolleginnen «mal schauen, ob es stark ist», macht aus der Prüfung eine Verbreitung. Musst du ein neues Passwort weitergeben, lege ein kurzes Geheimnis auf einen Einmal-Link und lass den Schlüssel hinter # in der URL. Eine Datei, die du mehrfach entschlüsselst, gehört in die Datei-Verschlüsselung. Die Prüfseite beantwortet «sieh dir Liste und Balken selbst an». Sie ist kein Schlüsselkanal.

Wo du anfängst

Starte mit einem Passwort, das du ohnehin ablösen willst, oder einem, das nie auf einem echten Konto stand. Öffne die Prüfseite, sieh den Wortlisten-Request im Network, tippe, dann bestätige, dass die Kette nicht rausgegangen ist. Trifft sie die Liste, behalte nicht zwei Zeichen und verwende sie weiter. Öffne den Passwortgenerator und erzeuge eines auf diesem Gerät, Länge 16 oder mehr. Kein Treffer heißt nur: Es ist kein Mitglied dieser öffentlichen Menge schwacher Passwörter. Hinterlege trotzdem je Dienst ein anderes Passwort.

Ist deine eigentliche Frage «stand dieses Passwort in einem bekannten großen Dump», reichen rund 860 lokale Zeilen nicht. Nimm ein Tool, das eine k-Anonymitäts-Bereichsabfrage fährt, und bestätige im Network, dass nur ein 5-Zeichen-Präfix rausging. Übergib das Original nicht an eine unbekannte Lookup-Seite. Nach beiden Checks gilt: Ein Tool, das ohne Anmeldung aufgeht, ersetzt nicht den Login-Schutz jedes Dienstes — und es beweist nicht, dass ein Server später nie leakt.

Hast du das einmal durchgespielt, kannst du die Überschrift schon beantworten. Eine lokale Sperrliste beweist: «Sieht das aus wie der Schwung, den Angreifer zuerst versuchen.» Eine Netz-Passwortabfrage — korrekt gebaut — beweist: «Steht der volle Hash in dem Korpus, das die Gegenseite pflegt.» Die erste schickt eine Wortliste raus und behält das Passwort. Die zweite schickt ein Präfix raus und behält das Original. Ein drittes Design, das das Original POSTet, gehört zu keinem von beiden.

Häufige Fragen

Wenn die lokale Liste nicht trifft, soll ich trotzdem Have I Been Pwned prüfen?

Es hängt davon ab, welchen Satz du brauchst. Kein Treffer heißt nur: Die Zeichenkette steht nicht auf dieser öffentlichen Wortliste schwacher Passwörter. Willst du außerdem wissen, ob sie im Passwort-Hash-Korpus von HIBP vorkommt, führe eine eigene Bereichsabfrage und bestätige im Network, dass nur ein 5-Zeichen-Präfix rausging. Halte die zwei Checks getrennt. Falte sie nicht zu «ich habe schon das ganze Netz durchsucht» zusammen.

Verrät eine Bereichsabfrage HIBP mein Passwort?

Nach dem offiziellen Design und Troy Hunts Darstellung bekommt die Gegenseite die ersten fünf Zeichen eines SHA-1- oder NTLM-Hash — nicht das Passwort und nicht den vollen Hash. Der Abgleich endet in deinem Browser. Es bleibt ein ausgehender Request. Darfst du kein Präfix vom Gerät lassen, nutze nur die lokale Liste und akzeptiere die schmalere Abdeckung.

Brauche ich ein Konto, um ein Passwort zu prüfen? Wird das Testpasswort hochgeladen?

Kein Konto. Bei einem lokalen Design bleibt das Testpasswort im Eingabefeld. Rausgehen darf die Wortlistendatei plus Analytics-Events ohne Original. Ob eine Seite das wirklich tut, ist eine Network-Frage, kein Satz «wir laden nie hoch» auf der Seite.

Kann ich «Offline-Knackzeit: N Jahre» am Stärkebalken glauben?

Die Zahl ist ein Größenordnungshinweis bei fester Rate. Sie misst keine bestimmte Grafikkarte und keinen Wörterbuchangriff. Trifft die Liste, laufen Angreifer diese Uhr nicht ab. Nimm sie als Erinnerung, dass die Kette kurz ist oder zu wenige Zeichenklassen nutzt — nicht als Sicherheitsgarantie.