Rubrik: Technologie & KI Autor: V Leselänge: ~27 Min Quellen und weiterführende Literatur: 22 Einträge Themen: Passwortleck, Have I Been Pwned, Pwned Passwords, k-Anonymität, Credential Stuffing, DSGVO, ÚOOÚ SEO / Arbeitstitel: Wie finden Sie heraus, ob Ihr Passwort oder Ihre E-Mail durchgesickert ist?
Wie finden Sie heraus, ob Ihr Passwort oder Ihre E-Mail durchgesickert ist? Die Frage klingt einfach nur so lange, bis wir merken, dass wir nicht eine Sache vergleichen. Eine E-Mail in einem Leak ist kein Passwort in einem Leak. Ein Passwort in einem Korpus ist nicht „Ihr“ Passwort. Ein Fund im Index ist keine fremde Anmeldung. Und ein leeres Ergebnis ist kein Beweis, dass kein Leak geschehen ist. Der Artikel sucht deshalb keinen Sicherheitsknopf. Er sucht, welche Schicht Sie gerade messen und was aus ihr noch nicht folgt.
1. Eine Have-I-Been-Pwned-Benachrichtigung ist keine Nachricht, dass sich jemand gerade angemeldet hat
Am Morgen kommt eine E-Mail: Ihre Adresse ist in einem neuen Have-I-Been-Pwned-Eintrag aufgetaucht. Der Leser öffnet die Seite, sieht den Namen eines Dienstes und Kategorien von Daten. Im Kopf fügt sich das zu einem Satz: Jemand hat mein Passwort und gelangt gerade in meinen Posteingang. Ein Kollege aus der IT sagt, man solle nicht in Panik geraten und zuerst die Adresse vom Passwort trennen. Ein Jurist erinnert den Verantwortlichen an die Frist von 72 Stunden nach der DSGVO. Ein Banker spricht von Credential Stuffing auf anderen Websites. Der Betreiber eines Dienstes sagt, er habe den Nutzern eine Mitteilung geschickt.
Auf den ersten Blick geht es um ein Leak. In Wirklichkeit beschreibt jeder ein anderes Problem. Der Leser liest den Fund als lebende Sitzung. Die IT behandelt das Vorkommen eines Geheimnisses im Korpus. Der Jurist spricht von der Pflicht des Verantwortlichen gegenüber der Behörde und den betroffenen Personen. Der Banker meint ein wiederholtes Passwort bei einem anderen Dienst. Der Betreiber fragt, ob sein Vorfall ein Risiko schafft, das gemeldet werden muss.
Deshalb können alle teilweise recht haben und eine gemeinsame Entscheidung trotzdem falsch sein. Ein Fehler führt zu Panik und einem unnötigen Reset in ein schwächeres Passwort. Der andere führt zur Ruhe aus einem leeren Ergebnis und zur weiteren Verwendung desselben Passworts auf zehn Websites. HIBP ist kein Alarm über eine gerade laufende Anmeldung. Es ist ein Index bekannter Dateien und Vorfälle, mit eigenen Grenzen und einem Datum.
2. Eine Adresse hat mindestens sechs Schichten
Das Wort „durchgesickert“ wird für einen Dump aus einem kompromittierten Dienst, einen Paste auf einer Website, ein Stealer-Log vom Rechner eines Opfers, eine Stuffing-Liste und eine Mitteilung des Verantwortlichen verwendet. Diese Wörter sind nicht austauschbar. Wenn wir sie vertauschen, reagieren wir falsch: Wir ändern ein Passwort dort, wo das Problem die Wiederholung woanders war, oder wir schreiben eine Beschwerde dort, wo ein identifizierbarer Verantwortlicher im DSGVO-Regime fehlt.
Sechs Schichten einer Adresse:
- Rohstoff: Dump aus einem kompromittierten Dienst, Stealer-Log, Stuffing-Liste oder Paste. Jeder Typ entsteht anders.
- Index: Have I Been Pwned, Sentinel, ein Passwortmanager oder eine interne Prüfung eines Dienstes. Jeder Index hat einen anderen Korpus und eine andere Latenz.
- Fund: Adresse, Passwort oder ein Paar aus Adresse plus Passwort auf der Seite des Angreifers. HIBP verbindet für den Bürger Adresse und Passwort nicht.
- Missbrauch: Credential Stuffing auf anderen Websites, Phishing auf einen Reset, Verkauf eines Logs oder Anmeldung in ein Konto.
- Pflicht des Verantwortlichen: Artikel 33 und 34 DSGVO, Dokumentation des Vorfalls, Meldung an die ÚOOÚ und gegebenenfalls Mitteilung an die betroffenen Personen [13].
- Reaktion des Kontoinhabers: einzigartiges Passwort, Änderung dort, wo es wiederholt wurde, widerstandsfähigerer zweiter Faktor, Prüfung der Sitzungen und Behandlung eines Schadens.
Ein Index ist kein Rohstoff. Ein Fund ist kein Missbrauch. Die Pflicht des Verantwortlichen ist nicht die Pflicht des Bürgers. Und die Reaktion des Nutzers soll der Schicht entsprechen, die er gerade sieht. Ein Mensch muss nicht wissen, wie Stuffing durchgeführt wird. Er muss wissen, warum ein wiederholtes Passwort einem alten Dump ein neues Leben gibt.
Diese Schichtung ändert auch die Sprache. „Ich habe eine E-Mail in einem Leak“ ist der richtige Beginn, nicht das Ende der Diagnose. Es muss ergänzt werden, ob es um einen Dienst ging, den der Mensch genutzt hat, welche Datenkategorien angegeben sind, ob dort ein Passwort war, ob das Passwort einzigartig war und ob es irgendwo wiederholt wurde. Erst danach kommt die Reaktion. Ohne diesen Zwischensatz wird Sicherheit zum Ritual: klicken, erschrecken, etwas ändern, sich beruhigen.
Eine E-Mail in einem Leak ist nicht dasselbe wie ein Passwort in einem Leak. Und ein Passwort in einem Leak ist noch keine fremde Anmeldung.
— Jiný Kontext
3. Die beste Reaktion ist die, deren Irrtum Sie nicht aussperrt und kein Stuffing öffnet
Eine gute Sicherheitsreaktion ist nicht die lauteste. Es ist eine Reaktion, die das Risiko senkt und kein neues schafft. Ein unnötiger Reset eines Dienstes ist ein billiger Fehler. Ein Reset in ein kurzes, wiederholtes oder vergessliches Passwort ist schlechter. Die Eingabe des vollen Passworts in einen zufälligen „Prüfer“ ist selbst ein Leak. Und die Ruhe aus einem leeren Index kann teuer sein, wenn dasselbe Passwort woanders verwendet wird.
| Art des Versagens | Wie es aussieht | Wie prüfen | Was den Schaden begrenzt |
|---|---|---|---|
| Fehlalarm | Die Adresse ist in HIBP, aber das Passwort war einzigartig und MFA hält | Dienst und Datenkategorien lesen, nicht nur das Wort Breach | Nur dort ändern, wo ein Grund bestand |
| Falsche Ruhe | HIBP zeigt nichts, aber das Passwort ist auf mehreren Websites dasselbe | K-anonyme Passwortprüfung und Passwortmanager | Einzigartige Passwörter und Benachrichtigungen |
| Leak in einen Prüfer | Das volle Passwort geht an einen unbekannten Dienst | Nur offizielle Pwned Passwords oder einen Passwortmanager verwenden | Niemals ein Geheimnis per E-Mail senden |
| Verwechslung von Stuffing und Phishing | Ein historischer Fund wird behandelt, aber der Mensch gibt eine Angabe an einen Betrüger ein | Alten Dump vom lebenden Kanal trennen | Prüfung außerhalb des Links und widerstandsfähigere MFA |
| Falscher Adressat | Eine Beschwerde zielt auf die ÚOOÚ ohne Bezug zum Verantwortlichen | Fragen, wer der Verantwortliche ist und was er tun sollte | Art. 34, Art. 77 und Belege |
Diese Tabelle soll eine gesunde Furcht nicht ersetzen. Sie soll sie genauer machen. Die Sicherheit eines Kontos entsteht nicht aus einer Webantwort. Sie entsteht daraus, dass ein Geheimnis nicht wiederholt wird, der zweite Faktor nicht nur ein leicht abschreibbarer Code in jeder Lage ist, Sitzungen geprüft werden können und der Mensch weiß, wann es nicht mehr um einen Index geht, sondern um den Verdacht auf einen fremden Zugang.
Die Reaktion soll auch eine Reihenfolge haben. Zuerst wird der Zugang zum Konto gesichert, damit sich der Mensch nicht selbst aussperrt. Dann wird das Passwort dort geändert, wo ein Grund besteht. Dann wird geprüft, ob dasselbe Passwort woanders gelebt hat. Zuletzt werden Benachrichtigungen und ein zweiter Faktor eingeschaltet, der für den gegebenen Dienst Sinn ergibt. Wird die Reihenfolge umgekehrt, kann der Mensch den Wiederherstellungskanal verlieren, das Passwort durch eine Variante des alten überschreiben oder einen historischen Index erledigen und eine lebende Sitzung offen lassen.
4. Eine E-Mail im Index ist kein Passwort im Index
Have I Been Pwned trennt die Suche nach einer E-Mail-Adresse in einem Breach vom Dienst Pwned Passwords. Zur Adresse sieht der Mensch Dienste und Datenkategorien. Er sieht sein Passwort nicht neben der Adresse. HIBP erklärt in den FAQ, dass Passwörter nicht so gespeichert werden, dass sie für die öffentliche Suche mit Adressen verbunden wären [4]. Das ist eine Sicherheitsgrenze des Dienstes, kein kosmetisches Detail.
Zum 1. September 2026 nannte die HIBP-Startseite 17 796 310 183 indexierte Konten und 1 033 gepwnte Websites oder Vorfälle [1]. Diese Zahlen sind lebende Zähler eines globalen Dienstes. Sie messen Konten oder Adressen im Index, nicht einzigartige Menschen und nicht die Zahl der Opfer in Tschechien. Ein Mensch kann mehrere Adressen haben. Eine Adresse kann in mehreren Vorfällen stehen. Ein Vorfall kann nur eine E-Mail enthalten und ein anderer eine breitere Menge von Kategorien.
Die praktische Frage lautet deshalb nicht „bin ich gehackt?“. Sie lautet: Welcher Dienst ist genannt, welche Datenkategorien werden bei ihm angegeben und habe ich dort ein Passwort verwendet, das auch woanders wiederholt wurde. Wenn ja, liegt das Problem nicht nur beim alten Dienst. Es liegt an allen Stellen, an denen dasselbe Geheimnis dieselbe Tür geöffnet hat.
Datenkategorien sind auch deshalb wichtig, weil eine E-Mail oft nur ein Identifikator für weitere Angriffe ist. Für sich muss sie kein Konto öffnen. Sie kann jedoch einem überzeugenden Phishing, einer Reset-Kommunikation oder der Paarung mit einem anderen Leak helfen. Daraus folgt nicht, dass jede gefundene Adresse einen Schaden bedeutet. Es folgt, dass eine Adresse im Index ein anderes Gewicht hat als ein Passwort im Korpus und ein anderes Gewicht als eine bestätigte fremde Sitzung.
5. Ein Passwort in Pwned Passwords ist nicht „Ihr“ Passwort
Pwned Passwords misst das Vorkommen eines Geheimnisses in einem Korpus bekannter durchgesickerter Passwörter. Wenn ein Passwort gefunden wird, bedeutet das nicht, dass der Dienst weiß, dass es gerade Ihnen gehört hat. Es bedeutet, dass dasselbe Geheimnis irgendwo im Korpus aufgetaucht ist. Wenn Sie es jemals verwendet haben, ist es als öffentlich und für die weitere Verwendung ungeeignet zu behandeln.
Die Seite Pwned Passwords nannte zum 1. September 2026 einen Betrieb von mehr als 18 Milliarden Anfragen im Monat, einen Cache-Treffer über 99,9 % und 335 Edge-Standorte [2]. Das misst den Betrieb des Dienstes und die Einbindung von Passwortmanagern, Registrierungsformularen und manuellen Prüfungen. Es misst nicht die Zahl neuer Leaks und nicht die Zahl der Menschen, deren Passwort missbraucht wurde.
Der Unterschied zwischen „das Passwort wurde gefunden“ und „jemand hat sich angemeldet“ ist grundlegend. Das Erste ist der Zustand eines Geheimnisses. Das Zweite ist ein Ereignis in einem konkreten Konto. Den Zustand des Geheimnisses lösen wir durch eine Änderung überall dort, wo das Passwort wiederholt wurde, und durch ein neues einzigartiges Passwort. Ein Ereignis im Konto lösen wir durch Sitzungen, Anmeldeprotokolle, den Support des Dienstes und bei Schaden durch die Bank oder die Polizei. Eine Schicht darf die andere nicht verschlucken.
6. Eine Stuffing-Liste ist nicht das Leak einer Firma
Credential Stuffing ist der Missbrauch bereits bekannter Paare von Anmeldedaten gegen andere Dienste. OWASP unterscheidet ihn von Brute Force und von Password Spraying [17]. Der Kern ist nicht, ein Passwort immer wieder zu raten. Der Kern ist die Wiederholung alter Geheimnisse dort, wo Menschen dasselbe Passwort mehrfach verwendet haben.
Troy Hunt hat den im November 2025 in HIBP aufgenommenen Korpus Synthient Credential Stuffing Threat Data beschrieben. Er nennt 1 957 476 021 einzigartige E-Mail-Adressen, rund 1,3 Milliarden einzigartige Passwörter und 625 Millionen Passwörter, die HIBP zuvor nicht gesehen hatte [6]. Der HIBP-Eintrag zu diesem Korpus beschreibt ihn als Stuffing-Daten, nicht als Leak einer Firma [7].
Im selben Text werden 32 Millionen Domains und 394 Millionen Adressen auf der Domain gmail.com genannt, also etwa 20 % der Adressen in diesem Korpus [6]. Das ist kein Leak von Gmail. Es ist ein Zeichen, dass eine große Freemail-Domain in recycelten Anmeldepaaren auftaucht. Wer diese Zahl als Kompromittierung von Google liest, hat den Nenner vertauscht.
Daraus folgt keine Anleitung zum Angriff. Es folgt eine Verteidigungsregel: Ein altes Passwort darf nicht wiederholt werden. Wurde es wiederholt, wird es überall geändert, wo es verwendet wurde, nicht nur beim in der Mitteilung genannten Dienst. Das neue Passwort soll keine Variante des alten sein. Ein Passwortmanager ist kein zusätzlicher Komfort. Er ist eine Weise, das Recycling von Geheimnissen zu stoppen.
Stuffing erklärt auch, warum alte Leaks nicht aus dem Leben verschwinden, nur weil der alte Dienst untergegangen ist. Der Wert eines Paares aus Adresse und Passwort liegt nicht nur in der ursprünglichen Website. Er liegt in der Möglichkeit, dass der Mensch dasselbe Geheimnis woanders verwendet hat. Die Verteidigung besteht deshalb nicht darin, um jeden Preis den ursprünglichen Schuldigen zu suchen. Sie besteht darin, dass die Wiederholung beseitigt wird und künftige Anmeldungen sich nicht auf dasselbe Geheimnis stützen.
7. Ein Stealer-Log ist nicht dasselbe wie das Leak eines Betreibers
Ein Stealer-Log entsteht anders als das Leak der Datenbank eines Betreibers. Schadsoftware auf dem Gerät des Opfers kann gespeicherte Anmeldedaten, Cookies oder andere Angaben aus der Umgebung des Nutzers sammeln. Die Kompromittierung einer Firma bedeutet ein Versagen beim Verantwortlichen eines Dienstes. Beide Ergebnisse können auf demselben Markt für Daten enden. Ursache, Verantwortung und Reaktion sind jedoch andere.
Verizon nennt im Zusatz zum DBIR 2025, dass kompromittierte Daten der Anfangsvektor bei 22 % der Breaches aus 9 891 Vorfällen mit bekanntem Vektor waren, außerhalb der Kategorien Error und Misuse [16]. Dasselbe Material nennt bei 14 742 Infostealer-Geräten einen Median von 49 % einzigartiger Passwörter über Dienste hinweg, was bedeutet, dass in dieser Population von Malware-Opfern im Median 51 % wiederholte Passwörter lagen [16]. Es handelt sich um einen Verizon-Datensatz, nicht um die tschechische Bevölkerung und nicht um alle Nutzer.
Verizon nennt außerdem, dass in SSO-Logs Credential Stuffing im Median 19 % der Authentisierungsversuche bei 2 301 Organisationen ausmachte [16]. Das ist eine Messung in Organisationen und Logs, nicht die Zahl der Anmeldungen in Ihr Konto. Dennoch zeigt es den Mechanismus: Ein wiederholtes Passwort verwandelt ein altes Leak in einen laufenden Druck auf andere Dienste.
Ein Stealer-Log fügt noch eine Lehre hinzu. Manchmal genügt es nicht, das Passwort bei dem Dienst zu ändern, der im Index aufgetaucht ist. Lag das Problem auf dem Gerät, muss der Mensch das Gerät behandeln. Aktualisierungen, Entfernung schädlicher Software, Prüfung des Browsers und der Sitzungen gehören zu einer anderen Schicht als ein E-Mail-Fund. Dieser Text gibt kein Verfahren zur Gewinnung von Logs und zu ihrer Verwendung. Er trennt nur die Ursache: Ein Versagen beim Betreiber ist nicht dasselbe wie ein infiziertes Gerät des Nutzers.
8. K-Anonymität misst ein Präfix. Nicht das Vertrauen in einen zufälligen Prüfer
Pwned Passwords verwendet ein k-anonymes Suchmodell. Der Client berechnet den SHA-1-Abdruck des Passworts und sendet nur die ersten 5 Hex-Zeichen. Mögliche Präfixe gibt es 1 048 576, weil 16^5 [5]. Der Server gibt die passenden Suffixe und die Zahlen der Vorkommen zurück. Das volle Passwort verlässt das Gerät weder als lesbarer Text noch als ganzer Hash.
Die HIBP-API v3 beschreibt die Range-Suche und die Wahrung des Prinzips der Teilabfrage [3]. Der Server sieht also nicht das ganze Passwort. Er sieht nur das Präfix des Abdrucks. Das bedeutet nicht, dass Sie ein Passwort überallhin senden sollen, wo das Wort „Checker“ auftaucht. Es bedeutet, dass ein konkreter, sichererer Mechanismus existiert, den offizielle Pwned Passwords und manche Passwortmanager verwenden.
NIST SP 800-63B empfiehlt, gewählte Passwörter gegen Listen bekannter kompromittierter Werte zu prüfen [8]. Das ist eine Empfehlung für eine richtige Passwortverwaltung. Es ist keine allgemeine tschechische gesetzliche Pflicht aller Verantwortlichen, gerade HIBP zu verwenden. Und es ist keine Entschuldigung für das Sammeln voller Passwörter in einem zufälligen Webformular.
K-Anonymität erfüllt hier eine bescheidene Rolle. Sie sagt nicht, dass ein Passwort stark ist. Sie sagt nicht, dass ein Konto sicher ist. Sie sagt, ob das gegebene Geheimnis in einem bekannten Korpus aufgetaucht ist. Ein schwaches, aber bisher nicht durchgesickertes Passwort kann trotzdem eine schlechte Wahl sein. Ein starkes und einzigartiges Passwort, das einmal in einen öffentlichen Korpus gelangt ist, soll nicht mehr verwendet werden. Die Prüfung eines Leaks ist eine Bremse, nicht das ganze Sicherheitssystem.
Wie Sie ein Passwort prüfen, ohne das Geheimnis zu senden
Verwenden Sie offizielle Pwned Passwords oder einen Passwortmanager, der die Prüfung mit k-Anonymität durchführt. Geben Sie das volle Passwort nicht auf einer unbekannten Seite ein, senden Sie es nicht per E-Mail und prüfen Sie keine fremden Kombinationen. Der Zweck ist festzustellen, ob Ihr Geheimnis schon kein Geheimnis mehr ist. Nicht zu prüfen, ob sich mit einer fremden Kombination irgendwo eintreten lässt.
9. Sentinel ist nicht dasselbe wie Have I Been Pwned
CZ.NIC hat Sentinel View als ein Werkzeug beschrieben, das die Prüfung von Passwörtern gegen Daten aus dem Netz Turris Sentinel erlaubt und das Prinzip eines Teil-Hash verwendet [18]. Ein weiterer Text von CZ.NIC verbindet die Regeln für die Bildung eines Passworts mit dem Turris Sentinel Report [19]. Es ist ein naher Verteidigungsgedanke: nicht das ganze Geheimnis zu senden, sondern es mit einem Korpus bekannter Vorkommen zu vergleichen.
Sentinel ist jedoch nicht HIBP. Es hat eine andere Datenquelle, einen anderen Umfang und einen anderen Auftrag. Ein leeres Ergebnis in Sentinel reinigt HIBP nicht. Ein leeres HIBP reinigt Sentinel nicht. Kein Index kann versprechen, dass ein Passwort nie durchgesickert ist oder dass niemand gerade eine Anmeldung versucht. Die Abwesenheit eines Funds ist nur die Abwesenheit eines Funds in dem gegebenen Korpus.
Das ist der Grund, warum Indizes nicht als Wettstreit von Autoritäten verwendet werden sollen. Der eine kann ein Passwort aus seiner Umgebung fangen, der zweite einen globalen öffentlichen Dump, der dritte eine Prüfung innerhalb eines Passwortmanagers. Ein Widerspruch zwischen ihnen muss keinen Fehler bedeuten. Oft bedeutet er eine andere Quelle, eine andere Zeitlage und andere Regeln der Aufnahme. Der Verteidigungsschluss ist dabei einfach: Ein gefundenes Passwort wird ausgesondert, ein nicht gefundenes Passwort wird trotzdem nicht wiederholt.
Für den tschechischen Nutzer liegt der Wert von Sentinel darin, dass er einen weiteren Verteidigungsblick bietet, ohne mit Angriffslisten arbeiten zu müssen. Meldet der Dienst ein Vorkommen, wird das Passwort nicht verwendet. Meldet er nichts, gelten trotzdem die Einzigartigkeit des Passworts und der zweite Faktor. Sicherheit darf sich nicht auf eine leere Seite stützen.
10. Eine Meldung an die ÚOOÚ ist keine Beschwerde der betroffenen Person
Artikel 33 DSGVO sagt, dass der Verantwortliche eine Verletzung des Schutzes personenbezogener Daten der Aufsichtsbehörde möglichst binnen 72 Stunden ab dem Zeitpunkt meldet, zu dem er von ihr Kenntnis erlangt hat, es sei denn, die Verletzung führt voraussichtlich nicht zu einem Risiko für die Rechte und Freiheiten natürlicher Personen [13]. Die ÚOOÚ hat dazu eigene Informationen und ein Formular [11]. Diese Frist ist eine Pflicht des Verantwortlichen. Nicht des Bürgers.
Die ÚOOÚ nennt im Jahresbericht für das Jahr 2024 insgesamt 336 Meldungen von Verletzungen des Schutzes personenbezogener Daten [9]. Im Jahresbericht für 2025 nennt sie 392 Meldungen, die höchste Zahl seit der Wirksamkeit der DSGVO [10]. Diese Zahlen messen Meldungen der Verantwortlichen an die tschechische Aufsichtsbehörde. Sie messen nicht die Zahl durchgesickerter Passwörter von Bürgern, die Zahl der Einträge in HIBP und nicht die Größe konkreter Dumps.
Eine Beschwerde der betroffenen Person ist eine andere Sache. Die ÚOOÚ nennt im Bericht für das Jahr 2025 insgesamt 3 854 Eingaben, davon 2 514 Beschwerden und 1 340 Anregungen, um 68 % mehr als im Jahr 2024 [10]. Es handelt sich um eine Mischung von DSGVO-Agenden, nicht nur um Passwortlecks. Eine Beschwerde nach Artikel 77 verlangt einen Bezug zu einem bestimmten Verantwortlichen und bei der ÚOOÚ ein authentisiertes Verfahren [12] [13]. Ein Fund in HIBP muss selbst nicht sagen, wem und was vorgeworfen werden kann.
11. Eine Mitteilung an betroffene Personen ist nicht dasselbe wie der HIBP-Index
Artikel 34 DSGVO regelt die Mitteilung einer Verletzung des Schutzes personenbezogener Daten an die betroffene Person, wenn die Verletzung voraussichtlich ein hohes Risiko für die Rechte und Freiheiten natürlicher Personen zur Folge hat [13]. Der EDSA und die ursprüngliche WP29 haben dazu die Leitlinien WP250 herausgegeben [14]. Diese Mitteilung kommt vom Verantwortlichen. Sie soll sagen, was geschehen ist, welche Daten den Menschen betreffen und was er tun soll.
HIBP ist eine andere Institution, in Anführungszeichen und ohne sie. Es indexiert bekannte öffentlich durchgesickerte Dateien und Vorfälle. Es kann eine Adresse in einem alten Dump zeigen. Es muss keinen nichtöffentlichen Vorfall haben, den der Verantwortliche den betroffenen Personen mitgeteilt hat. Und es kann einen historischen Eintrag haben, zu dem der Verantwortliche nicht mehr kommuniziert. In dem einen zu sein bedeutet nicht, in dem anderen zu sein.
Vor einer Beschwerde an die ÚOOÚ
Stellen Sie zuerst drei Fragen. Wer ist der Verantwortliche? Welche Pflicht sollte verletzt worden sein? Welchen Beleg haben Sie: eine Mitteilung, eine Kommunikation, die Ablehnung eines Antrags oder nur einen öffentlichen Index? Artikel 78 Abs. 2 DSGVO arbeitet mit der Unterrichtung des Beschwerdeführers über den Fortgang oder das Ergebnis der Beschwerde binnen drei Monaten [13]. Das ist keine Frist für die Löschung aus HIBP.
12. Ein Fund im Index ist kein Beweis einer fremden Anmeldung. Ein leeres Ergebnis ist kein sauberes Konto
Die HIBP-FAQ arbeitet ausdrücklich mit der Grenze der Abwesenheit eines Beweises: absence of evidence is not evidence of absence [4]. Wenn eine Adresse nicht gefunden wird, wissen wir nicht, dass sie nie durchgesickert ist. Wir wissen nur, dass sie nicht in dem gegebenen Index steht. Wenn sie gefunden wird, wissen wir nicht, dass sich jemand gerade angemeldet hat. Wir wissen, dass sie in einer bekannten Datei oder einem Vorfall aufgetaucht ist.
Diese doppelte Verneinung ist unangenehm, aber befreiend. Sie gibt keine Gewissheit, verhindert aber einen falschen Schluss. Ein Fund führt zur Prüfung, nicht zur Panik. Ein leeres Ergebnis führt zur Bewahrung guter Gewohnheiten, nicht zur Wiederholung von Passwörtern. Ein Index ist kein Wächter von Sitzungen. Er sieht keine aktuelle Anmeldung bei der Bank, der E-Mail oder einem sozialen Netz.
Besteht der Verdacht auf eine fremde Anmeldung, ändert sich das Vorgehen. Es werden Sitzungen, angemeldete Geräte, Regeln der Mailweiterleitung, Passwortänderungen, der zweite Faktor und Hinweise des Dienstes geprüft. Bei Schaden oder einem Versuch finanziellen Missbrauchs werden Bank, Betreiber des Dienstes und nach den Umständen die Polizei eingeschaltet. Das ist kein Artikel über einen Leak-Index mehr.
Ebenso vorsichtig soll auch der Hinweis eines Passwortmanagers gelesen werden. Wenn ein Passwortmanager mitteilt, dass ein Passwort kompromittiert ist, sagt er meist nicht, dass jemand ein konkretes Konto geöffnet hat. Er sagt, dass das Geheimnis einem bekannten kompromittierten Wert oder einem Eintrag in einem überwachten Dienst entspricht. Das ist ein Grund, das Geheimnis auszutauschen und die Wiederverwendung zu beseitigen. Es ist nicht selbst ein Beweis eines Schadens.
Ein leeres Ergebnis ist kein sauberes Konto. Ein Fund ist keine gerade laufende Anmeldung.
— Jiný Kontext
13. MFA senkt Stuffing. Sie stoppt kein Phishing, in das Sie das Passwort selbst eingeben
Ein zweiter Faktor senkt die Wirkung eines wiederholten Passworts. Kennt der Angreifer ein altes Paar aus E-Mail und Passwort, kann ein zweiter Faktor die Anmeldung verhindern. Das ist der Grund, warum MFA auch nach Jahren alter Leaks Sinn hat. Es ist jedoch kein undurchdringlicher Schild gegen jeden Kanal.
Phishing, bei dem der Mensch selbst Passwort und einen weiteren Code in eine betrügerische Oberfläche eingibt, ist ein anderer Mechanismus als das historische Vorkommen eines Passworts in einem Korpus. Dieser Text beschreibt keine Umgehungstechniken und keinen Angriff in Echtzeit. Die Unterscheidung genügt: HIBP zeigt einen historischen Fund in bekannten Daten. Phishing ist ein lebender Kanal, der eine gute Gewohnheit umgehen kann, wenn der Mensch einem falschen Link folgt.
Daraus folgt eine nüchterne Regel. Nach einem Fund werden Passwort, Wiederverwendung und MFA behandelt. Bei einem verdächtigen Link werden die Prüfung außerhalb des Links, die direkte Eingabe der Adresse des Dienstes und der Kontakt über einen bekannten Kanal behandelt. Eine Verteidigung ersetzt die andere nicht. Ein Passwort in Pwned Passwords ist kein Beweis für Phishing, aber ein wiederholtes Passwort verbilligt die Folgen von Phishing.
14. Ein sensibles Breach ist nicht dasselbe wie ein öffentlich durchsuchbarer Dump
HIBP unterscheidet sensible Breaches, die ohne Prüfung des Eigentums am Postfach nicht öffentlich durchsuchbar sind. Die FAQ nannte zum 1. September 2026 insgesamt 87 sensitive Breaches und 2 retired Breaches [4]. Das misst eine Klassifikation innerhalb von HIBP, nicht die Sensibilität jedes wirklichen Leaks in der Welt.
Der Grund ist einfach. Manche Vorfälle verraten schon dadurch eine empfindliche Information, dass ein Mensch in dem Dienst war. Eine öffentliche Antwort „ja, diese Adresse ist in diesem Vorfall“ könnte einen neuen Schaden verursachen. Deshalb hat der Dienst einen Modus, in dem das Eigentum am Postfach geprüft werden muss. Ein Index ist also nicht nur eine Datenbank. Er ist auch eine Entscheidung, was wem gezeigt werden darf.
Dieselbe FAQ nennt Plus-Aliasing bei etwa 0,03 % der Adressen und erklärt, dass der Dienst es nicht vollständig achtet [4]. Eine kleine Zahl kann eine große praktische Wirkung haben. Wenn ein Mensch eine Adresse vom Typ name+dienst@domain verwendet, kann ein Fund oder Nichtfund falsch gelesen werden. Wieder geht es nicht um ein sauberes Konto. Es geht um eine technische Regel des Index.
15. ENISAs sechzig Prozent Phishing sind nicht der tschechische Anteil durchgesickerter Passwörter
ENISA nennt im Threat Landscape 2025, dass Phishing etwa 60 % der beobachteten Fälle als Intrusion Vector im Zeitraum vom 1. Juli 2024 bis zum 30. Juni 2025 bildete [15]. Zugleich nennt das Material, dass 77 % der Vorfälle im Datensatz DDoS waren und dass sich bei den Eindringungen 8,9 % auf Credential Theft bezogen [15]. Diese Zahlen haben verschiedene Nenner.
Gerade deshalb dürfen sie nicht zu einem Satz über tschechische Passwörter addiert werden. ENISA misst die europäische Bedrohungslandschaft und Kategorien von Vorfällen in ihrem Datensatz. HIBP misst bekannte Breaches und Adressen im Index. Die ÚOOÚ misst Meldungen der Verantwortlichen und Beschwerden. Verizon misst seine Vorfälle und Organisationen. Jede Zahl kann wahr und trotzdem für einen anderen Schluss unbrauchbar sein.
NÚKIB kann ein nützlicher Kontext für tschechische Organisationen sein, aber die Zahl der Vorfälle im Bericht über den Stand der Cybersicherheit ist kein Proxy für die Zahl der Bürger mit einem Passwort in HIBP [21]. Europol beschreibt wiederum den Markt mit kompromittierten Konten und die Kriminalität um sie [22]. Das hilft, die Motivation der Angreifer zu verstehen. Es ist keine Anleitung und kein individueller Audit eines Postfachs.
16. Ein kurzer Expositionstest verspricht keine Sicherheit
Der Sinn des Tests ist, die Exposition festzustellen, nicht fremde Angaben zu gewinnen und nicht zu prüfen, ob sich ein Konto knacken lässt. Das muss auch in den kleinen Schritten sichtbar bleiben. Die eigene E-Mail wird auf dem offiziellen HIBP geprüft. Das eigene Passwort wird über Pwned Passwords oder einen Passwortmanager mit k-Anonymität geprüft. Fremde Kombinationen werden nicht versucht. Stuffing-Listen werden nicht heruntergeladen.
Drei Tests eines Funds
Der erste Test ist die Adresse. Geben Sie Ihre eigene E-Mail in das offizielle HIBP ein und lesen Sie die Ergebnisse nach Diensten und Datenkategorien. Suchen Sie nicht das Gefühl „ich bin gehackt“. Suchen Sie, ob es um E-Mail, Telefon, Passwort-Hash, Profildaten oder eine andere Kategorie ging. Stellen Sie Benachrichtigungen nur für das eigene Postfach ein.
Der zweite Test ist das Passwort. Prüfen Sie es nur mit k-Anonymität. Wird es im Korpus gefunden, behandeln Sie es als öffentlich. Ändern Sie es überall, wo es wiederholt wurde, und verwenden Sie keine Variante des alten Passworts. Dieser Satz ist kein Angriff. Er ist das Schließen eines Stuffing-Wegs.
Der dritte Test ist das Konto. Zeigt der Dienst fremde Sitzungen, unbekannte Geräte, Änderungen der Einstellungen oder einen finanziellen Schaden, ist HIBP nicht mehr das Hauptwerkzeug. Es geht um den Betrieb des Kontos. Änderung des Passworts, Abmeldung von Sitzungen, Prüfung des zweiten Faktors, Kontakt mit dem Dienst und bei Schaden Bank oder Polizei haben Vorrang vor einem weiteren Suchen im Index.
Wahlweise kann Sentinel View als anderer Korpus hinzugefügt werden [18]. Kommt eine Mitteilung des Verantwortlichen nach Artikel 34 DSGVO, folgen Sie ihr. Kommuniziert der Verantwortliche nicht oder verletzt er Rechte, wird eine Beschwerde nach Artikel 77 behandelt, nicht der Antrag, die ÚOOÚ solle einen öffentlichen Index löschen [12] [13].
Schreiben Sie das Ergebnis des Tests in drei Spalten: Adresse, Passwort, Konto. Zur Adresse gehören Dienst und Datenkategorien. Zum Passwort gehört die Entscheidung, wo es wiederholt wurde und wo es geändert wird. Zum Konto gehören Sitzungen, zweiter Faktor und unbekannte Änderungen. Diese Tabelle ist nicht spektakulär. Sie ist jedoch besser als der unbestimmte Satz „es ist mir durchgesickert“, weil jede Zeile einen anderen Schritt zeigt.
17. Die Frage lautet nicht, ob es durchgesickert ist. Sie lautet, welche Schicht Sie messen
Die Sicherheit eines Kontos ist keine Eigenschaft eines Index. Ein Index kann nützlich und trotzdem begrenzt sein. Er zeigt ein bekanntes Vorkommen einer Adresse oder eines Passworts. Er entsperrt kein Konto, löscht keine Daten aus dem Internet, bestätigt keine lebende Anmeldung und kann nicht beweisen, dass nichts durchgesickert ist. Das ist keine Schwäche eines Dienstes. Es ist die Grenze der gemessenen Schicht.
Die versteckte Kostenlast des Wortes „Leak“ ist der Verlust der Unterscheidung. Wenn E-Mail in einem Breach, Passwort im Korpus, Stuffing-Liste, Stealer-Log, Mitteilung des Verantwortlichen und fremde Sitzung in einen Satz fallen, wird die Reaktion zufällig. Einmal schießt sie über. Einmal verfehlt sie. Und manchmal öffnet sie genau den Weg, den sie schließen sollte.
Die Unterscheidung hilft auch dann, wenn nichts gefunden wurde. Ein leeres Ergebnis befreit nicht von der Passwortverwaltung. Es sagt nur, dass der gegebene Index keinen passenden Eintrag hat. Einzigartiges Passwort, Passwortmanager, sinnvoller zweiter Faktor und Prüfung der Sitzungen bleiben die Regel auch ohne rote Warnung. Sicherheit soll nicht auf einen Fund warten.
Ebenso soll ein Fund nicht die einzige Emotion bestimmen. Er soll den nächsten Schritt bestimmen. Die Adresse führt zum Lesen der Datenkategorien. Das Passwort führt zur Änderung des Geheimnisses. Die Mitteilung des Verantwortlichen führt zu seinen Anweisungen. Die Sitzung führt zum Schutz des Kontos. Wer diese Schritte trennt, muss nicht raten, ob er ruhig oder in Panik sein soll.
Die richtige Frage lautet deshalb nicht nur: „Ist mir das Passwort durchgesickert?“ Die richtige Frage lautet: „Welche Schicht habe ich gerade gemessen: einen bekannten Dump, einen Passwortabdruck, eine Stuffing-Liste, eine Meldung des Verantwortlichen oder eine fremde Sitzung, und was folgt aus ihr noch nicht?“ Erst danach hat es Sinn, das Passwort zu ändern, eine Mitteilung zu lesen, Sitzungen zu prüfen oder eine Beschwerde einzureichen. Nicht weil Panik eine Schwäche wäre. Weil eine ungenaue Reaktion ein weiteres Risiko ist.
Eine gute Antwort ist also weder „alles ist in Ordnung“ noch „alles ist verloren“. Eine gute Antwort ist kleiner und genauer. Eine E-Mail im Index wird als Spur in einer bekannten Datei gelesen. Ein Passwort in Pwned Passwords wird als Geheimnis gelesen, das nicht mehr geeignet ist, verwendet zu werden. Eine Stuffing-Liste wird als Warnung vor Wiederholung gelesen. Eine Mitteilung des Verantwortlichen wird als rechtliche und praktische Anweisung zu einem bestimmten Vorfall gelesen. Und eine fremde Sitzung wird als Betrieb des Kontos behandelt, nicht als weiteres Suchen im Netz.
Daraus folgt nicht, dass Indizes keinen Wert hätten. Es folgt, dass sie nur dann einen Wert haben, wenn sich an sie die richtige Schicht und der richtige Schritt binden. Have I Been Pwned, Sentinel View oder eine Mitteilung der ÚOOÚ hören dann auf, ein roter Knopf zu sein. Sie werden zur Karte. Eine Karte ist kein Schloss. Aber ohne Karte wird das Schloss blind gewechselt.
Verwandte Texte dieser Reihe
- Wie erkennt man eine betrügerische E-Mail, SMS oder einen Anruf? — Angriffskanal gegen Leak-Index.
- Was ist eine digitale Spur… — HIBP ist eine Schicht, nicht das ganze Internet.