Erkennung kompromittierter Passwörter mit HaveIBeenPwned und der Fastly KV Store Integration

In den letzten Jahren sind das vermehrte Auftreten von Datenschutzverletzungen und der Diebstahl von Zugangsdaten zur traurigen Realität geworden. Aufgrund der weit verbreiteten Mehrfachverwendung von Zugangsdaten ist es für Cyberkriminelle oft ein Leichtes, mithilfe von kompromittierten Anmeldedaten Account-Übernahmeangriffe (Account Takeover, ATO) durchzuführen. Zu den häufig verwendeten Angriffstechniken bei der Account-Übernahme gehört auch Credential Stuffing. Bei diesem Verfahren werden Listen mit kompromittierten Zugangsdaten durchforstet, um sich unbefugten Zugang zu Kundenkonten zu verschaffen. 

Da auch wir Zugriff auf kompromittierte Anmeldedaten in Form von Passwort-Hashes haben, können wir diese Art von Angriffen erkennen und stoppen. Die Passwort-Hashes werden von „HaveIBeenPwned“ (HIBP) zur Verfügung gestellt, einem Community-Service, der eine Datenbank mit kompromittierten Passwörtern unterhält und APIs bereitstellt, um auf datenschutzfreundliche Weise zu überprüfen, ob Passwörter an die Öffentlichkeit gelangt sind. In diesem Blogpost stellen wir Ihnen eine latenzarme Methode zur Erkennung von Pwning-Angriffen vor, bei der in einem KV Store auf der Fastly Edge gespeicherte Passwort-Hashes über Compute zu Rate gezogen werden.

Milliarden von kompromittierten Zugangsdaten

Laut HaveIBeenPwned beläuft sich die Zahl der kompromittierten Nutzerkonten (Stand: Februar 2024) auf 12,94 Milliarden. Dabei handelt es sich um die Gesamtzahl der geleakten Accounts auf verschiedenen kompromittierten Websites. In manchen Fällen überschneiden sich die Zugangsdaten auf unterschiedlichen Websites – beispielsweise bei Nutzung derselben Nutzername-Passwort-Kombination bei Google und Yahoo. Oft werden auch verschiedene Nutzernamen, aber dasselbe Passwort verwendet, was bei den zuvor genannten 12,94 Milliarden Accounts zu einer deutlich geringeren Zahl an einzigartigen Passwörtern führt.

Aus unserer Analyse des von HIBP bereitgestellten Datensatzes ergaben sich gerade einmal 931 Millionen einzigartige Passwörter. Da der Datensatz auch die Verwendungshäufigkeit jedes Passworts enthält, ergibt sich daraus eine Zahl von 6,93 Milliarden Anmeldedaten, was darauf schließen lässt, dass ein Anmeldedatenpaar im Durchschnitt für zwei verschiedene Nutzerkonten (also auf zwei Websites) verwendet wird. 

Manche Passwörter kommen häufiger zum Einsatz als andere. Zum Beispiel tauchte das Passwort „123456“ in 42 Millionen Zugangsdatenkombinationen auf, während „hunter2“ nur in 24.000 Fällen verwendet wurde. Das nachstehende Diagramm zeigt die Gesamtzahl der Zugangsdatenpaare und die entsprechende Anzahl der Passwörter, sortiert nach der Verwendungshäufigkeit der einzelnen Passwörter. Überraschenderweise werden nur 34 Millionen Passwörter (oder 3,6 % der kompromittierten Passwörter) bei 60 % der kompromittierten Anmeldedaten verwendet, was auf eine starke Mehrfachverwendung von Passwörtern schließen lässt. Daraus lässt sich wiederum ableiten, dass a) Nutzer dieselben Zugangsdaten auf mehreren Websites verwenden und b) verschiedene Nutzer dieselben Passwörter (in Kombination mit unterschiedlichen Nutzernamen) verwenden.

Abbildung 1: Zugangsdaten nach Anzahl der Passwörter aus dem Passwort-Hash-Datensatz von HaveIBeenPwned

Analog tauchen 532 Millionen Passwörter (57 % der kompromittierten Passwörter) bei 94 % der kompromittierten Anmeldedaten auf. Die lineare Entwicklung im Verhältnis 1:1 ab diesem Punkt deutet darauf hin, dass die übrigen 400 Millionen Passwörter einzigartig sind und wahrscheinlich von Passwortverwaltungstools generiert wurden, was sie für Cyberkriminelle bei Credential-Stuffing-Angriffen unbrauchbar macht. Abzüglich der 6 % an Zugangsdaten, die auf Passwortmanager zurückzuführen sind, bleiben immer noch 94 % oder 6,53 Milliarden Zugangsdatenpaare, die nachweislich für Credential-Stuffing-Angriffe geeignet sind.

Wie erkennt man Credential-Stuffing-Angriffe?

Durch Verwendung von Passwortmanagern zur Erstellung von eindeutigen Passwörtern für jede Website und zur Authentifizierung anhand dieser Passwörter lässt sich das Risiko von Credential-Stuffing-Angriffen komplett ausschließen. Das obige Diagramm zeigt zwar die kompromittierten Zugangsdaten, der Umfang des Datensatzes reicht aber auch aus, um repräsentative Aussagen über nicht kompromittierte Zugangsdaten zu treffen. So können wir schlussfolgern, dass die Nutzung von Passwortmanagern relativ wenig verbreitet ist, da nur knapp 6 % der Zugangsdaten von solchen Lösungen stammen.

Die Implementierung einer Multi-Faktor-Authentifizierung (MFA) mit ordnungsgemäßen Registrierungs- und Zurücksetzungsverfahren ist ebenfalls ein wirksamer Schutz vor Credential Stuffing und anderen Formen von Account-Übernahme-Angriffen. Der kürzlich eingeführte Passkeys-Standard ist ein bequemer und sicherer Anmeldemechanismus, der völlig ohne Passwörter auskommt. Diese Anmeldemethode ist derzeit zwar noch nicht allerorts etabliert, wir empfehlen aber, sie überall dort zu nutzen, wo sie verfügbar ist.

Wenn derartige Schutzmaßnahmen nicht möglich sind, ist es wichtig, Angriffe proaktiv zu erkennen und zu stoppen. Der NIST Leitfaden zur Einhaltung von Datenschutzstandards empfiehlt den Vergleich von Passwörtern mit „Passwörtern aus früheren Datenschutzverletzungen“ bei Anmeldung, Registrierung und dem Zurücksetzen von Passwörtern. 

In einem früheren Blogpost haben wir einen Ansatz zur Verwendung der Passwords API von HIBP mit Fastly Compute beschrieben, mit dem sich kompromittierte Passwörter in Anfragedaten erkennen lassen. In diesem Post stellen wir Ihnen eine neuartige Erkennungsmethode vor, die vollständig auf der Edge angesiedelt ist und ohne die Passwords API für jede Anfrage auskommt. Sie nutzt vielmehr hochgradig komprimierte Passwort-Hashes, die auf der Edge gespeichert werden. Das Ergebnis: Eine deutlich schnellere Erkennung, bei der Sie sich nicht auf die Verfügbarkeit von Drittanbietern verlassen müssen.

Kompromittierte Passwörter auf der Edge

Der latenzarme Zugriff auf den HIBP Datensatz wird durch das Speichern der Passwort-Hashes in einem Fastly KV Store erreicht. Beim KV Store handelt es sich um eine Art Container, mit dem Sie Daten in Form von Key-Value-Paaren speichern und dank eines schnellen Lese- und Schreibzugriffs auf der Edge im Handumdrehen nutzen können. Unser KV Store unterstützt eine unbegrenzte Zahl an Keys im UTF-8-Format (maximale Key-Größe: 1.024 Byte). Die Werte müssen als Text- oder Binärdatei mit einer maximalen Größe von 25 MB vorliegen. 

Leider handelt es sich bei dem Passwortdatensatz von HIBP um eine riesige Liste von SHA1-Hashes kompromittierter Passwörter, die derzeit in unkomprimierter Textform etwa 40 GB groß ist – Tendenz steigend. 

Weitere Optimierung mithilfe von Filtern und Partitionen

Wir sorgen dafür, dass der HIBP Datensatz als Filterdatenstruktur anstelle der unkomprimierten Textform bestehen bleibt, um den Ressourcenverbrauch (KV Store und Compute Speicher) zu minimieren und eine niedrige Latenzzeit beim Zugriff von Fastly Compute aus zu ermöglichen. Filter sind probabilistische Datenstrukturen, die Hash-Funktionen verwenden, um Elemente zu randomisieren und in kompakter Form darzustellen. Die Schlüsseleigenschaft von Filtern liegt in der Tatsache, dass es zwar zu falsch-positiven, aber nicht zu falsch-negativen Ergebnissen kommen kann. Mit anderen Worten besteht eine – wenn auch sehr geringe – Wahrscheinlichkeit, dass ein Passwort fälschlicherweise als kompromittiert gekennzeichnet wird. Ein kompromittiertes Passwort wird aber immer korrekt als solches erkannt. Durch die Darstellung der Hashes in einer Filterdatenstruktur konnten wir die Größe des Datensatzes um 97 % von 40 GB auf 1,08 GB reduzieren.

Abbildung 2: Anfragen werden vom Compute Service abgefangen, um sie auf kompromittierte Passwörter zu überprüfen

Um den Ressourcenverbrauch weiter zu verringern, werden Passwort-Hashes mithilfe eines 3-Zeichen-Präfixes gruppiert, wobei für jedes Präfix ein eigener Filter verwendet wird. Diese Filter werden anhand des dreistelligen Hash-Präfixes als verschlüsselte Werte im KV Store gespeichert. Nur die für das zu prüfende Passwort relevanten Präfix-Filter werden an den Compute Service übertragen. In der Regel sind diese jeweils ca. 266 KB groß.

Bei einer Anfrage, die ein Passwort enthält, generiert der Compute Service den SHA1-Hash für das Passwort und verwendet die ersten drei Zeichen des Hash, um das entsprechende Filterobjekt aus dem KV Store abzurufen. Um zu ermitteln, ob ein Passwort als kompromittiert einzustufen ist, nehmen wir die im Filter enthaltenen Passwort-Hashes unter die Lupe. Wir fügen dem Ergebnis den zusätzlichen Anfrage-Header „Fastly-Compromised-Password“ hinzu und leiten die Anfrage an den Origin-Server im Backend weiter. Dies ermöglicht es dem Backend, sein Verhalten entsprechend dem Kompromittierungsstatus des Passworts zu ändern. Bei einem kompromittierten Passwort kann das Backend entscheiden, ob es das Passwort ablehnt (z. B. bei der Registrierung), den Nutzer auf eine Seite zum Zurücksetzen des Passworts umleitet (z. B. beim Einloggen), ein Signal an einen Credential-Stuffing-Detektor sendet oder andere geeignete Maßnahmen ergreift.

Wir haben verschiedene Filteralgorithmen (darunter Cuckoo, XOR und BinaryFuse8) zusammen mit unterschiedlich langen Hash-Präfixen für die Datenpartitionierung im KV Store ausprobiert. Unter Berücksichtigung der Suchgeschwindigkeit, der Größe der generierten Filter, der Entwicklung der Filtergröße mit zunehmendem Datenvolumen und der Geschwindigkeit der Wiederherstellung der ursprünglichen Datenstruktur aus den Filtern haben wir festgestellt, dass dreistellige Präfixe mit BinaryFuse8 Filtern und 9-Bit-Fingerabdrücken am besten geeignet sind. Bei dieser Fingerabdruckgröße und den Auslastungsfaktoren für diesen Datensatz liegt die geschätzte Falsch-Positiv-Rate für den Filter bei etwa 0,3 %.

Demo- und Quellcode

Im Abschnitt „Demos“ des Fastly Developer Hub finden Sie eine Demo dieses Erkennungsansatzes. Probieren Sie das Ganze ruhig einmal selbst aus und behalten Sie die Ausführungsreihenfolge im Compute Service mit unseren Echtzeit-Logs im Auge. In den Abbildungen 3 und 4 finden Sie ein Beispiel für die Ausführung der Demo mit dem schwachen Passwort „hunter2“.

Abbildung 3: Die Zugangsdaten werden zu Demozwecken als Klartext angezeigt

Abbildung 4: Die Anfrage an das Backend wird mit dem Header „Fastly-Compromised-Password“ versehen

Zu Demozwecken stellen wir Ihnen den Open-Source-Code bereit, damit Sie die Erkennung kompromittierter Passwörter auf Ihrer Website implementieren können. Das Repository enthält auch den Code, den Sie brauchen, um Filter für die Hashes zu erstellen und diese in den KV Store hochzuladen. Wir empfehlen, die Filter vierteljährlich zu erneuern, um sie auf dem aktuellsten Stand zu halten.