Credential Stuffing: Das unterschätzte Compliance-Risiko

TL;DR: Obwohl kompromittierte Passwörter laut Verizon DBIR das Sicherheitsrisiko Nr. 1 sind, sichern die wenigsten Unternehmen ihren Login-Flow dagegen ab. Die Vorgaben von BSI und NIST sind jedoch eindeutig – und machen ungeprüfte Logins zu einem handfesten DSGVO-Compliance-Risiko.

Jedes Jahr veröffentlicht Verizon den Data Breach Investigations Report (DBIR), den globalen Branchenstandard für Security-Analysen. Und jedes Jahr zeigt sich dasselbe Bild: Gestohlene und geleakte Zugangsdaten führen die Liste der erfolgreichsten Angriffsvektoren unangefochten auf Platz 1 an. Auch wenn der Anteil durch die zunehmende Verbreitung von Multi-Faktor-Authentifizierung von über 80 % (2024/2025) auf aktuell knapp über 50 % im Jahr 2026 gesunken ist, bleibt die Kernaussage brisant: Kompromittierte Passwörter richten mehr Schaden an als das Ausnutzen technischer Schwachstellen im Code.

Genau hier liegt die prekäre Schieflage der modernen IT-Sicherheit. Unternehmen investieren massiv in Penetrationstests, automatisierte Vulnerability-Scanner und Bug-Bounty-Programme, um selbst kleinste Lücken in der eigenen Infrastruktur zu schließen. Der mit Abstand größte Angriffsvektor im Web – das Verhalten der Nutzerschaft und deren recycelte Passwörter – wird hingegen bei der Architektur des Login-Flows fast flächendeckend ignoriert.

So funktioniert Credential Stuffing

Der Ablauf eines Account Takeovers (ATO) ist simpel und hebelt selbst die sicherste Backend-Architektur aus: Ein Großteil der Nutzerschaft verwendet Passwörter dienstübergreifend. Wird ein beliebiges Drittsystem im Netz kompromittiert, landen die erbeuteten E-Mail- und Passwort-Kombinationen in öffentlich zugänglichen Datenbanken im Netz.

Kriminelle nutzen diese Listen und automatisieren den Login-Prozess bei unzähligen anderen Diensten. Das System erkennt eine formal korrekte E-Mail-Adresse und das dazugehörige, korrekte Passwort. Der Login wird autorisiert. Es findet kein klassischer Einbruch in die Infrastruktur statt – der unbefugte Zugriff erfolgt schlichtweg mit validen, aber extern kompromittierten Zugangsdaten.

DSGVO und rechtliche Meldepflichten

Viele Unternehmen betrachten kompromittierte Accounts fälschlicherweise als reines Support-Problem. Juristisch betrachtet ist die Sachlage jedoch eine andere: Ein Account Takeover ist ein Datenschutzvorfall.

Sobald durch Credential Stuffing Zugriff auf das Profil einer Person erlangt wird und dort personenbezogene Daten (Rechnungsadressen, Bestellhistorien, Verträge) einsehbar sind, greift Artikel 33 der DSGVO. Das Unternehmen ist verpflichtet, diesen Vorfall den Aufsichtsbehörden zu melden. Die Argumentation, die betroffenen Personen hätten "selbst ein unsicheres Passwort gewählt", schützt Betreiberunternehmen nicht vor der rechtlichen Mitverantwortung, wenn der Angriff durch etablierte technische Maßnahmen hätte verhindert werden können.

Die Vorgaben von NIST und BSI sind eindeutig

Dass der Abgleich von Passwörtern gegen Leak-Datenbanken keine Kür, sondern eine technische Notwendigkeit ist, wird von den wichtigsten Standardisierungsorganisationen offiziell gefordert:

• NIST (National Institute of Standards and Technology): In der Richtlinie SP 800-63B (Digital Identity Guidelines) schreibt das NIST in Abschnitt 5.1.1.2 unmissverständlich vor, dass Systeme bei der Passwortvergabe prüfen müssen ("shall compare"), ob das gewählte Passwort in Listen kompromittierter Zugangsdaten auftaucht.
• BSI (Bundesamt für Sicherheit in der Informationstechnik): Das BSI hat seine Vorgaben in den letzten Jahren fundamental modernisiert. Der Zwang zum regelmäßigen, anlasslosen Passwortwechsel wurde abgeschafft. Stattdessen fordert das BSI im aktuellen IT-Grundschutz-Kompendium (Baustein ORP.4), dass Passwörter zwingend gegen Wörterbücher und Listen bekannter, geleakter Passwörter geprüft werden müssen.

Warum das Risiko in der Praxis ignoriert wird

Wenn die Bedrohungslage durch den DBIR belegt ist und die Vorgaben von NIST und BSI eindeutig sind, stellt sich eine kritische Frage: Warum fehlt der Leak-Check in der überwältigenden Mehrheit der europäischen Web-Anwendungen?

Die Ursachen dafür liegen nicht in mangelnder technischer Expertise, sondern in einer Kette aus strukturellen Hürden:

1. Feature-Druck verdrängt Security-Themen
   Moderne Web-Frameworks (wie Laravel, Django oder Spring) machen die grundlegende Authentifizierung glücklicherweise extrem einfach. Sie bringen starkes Password-Hashing und Session-Management von Haus aus mit. Die Realität in der Produktentwicklung ist jedoch oft: Sobald der Login technisch funktioniert, gilt das Ticket als "erledigt". Im Alltag liegt der Fokus von Produktverantwortlichen und der Geschäftsführung verständlicherweise auf neuen Features, die direkten Business Value generieren. Zusätzliche Security-Schichten wie ein Leak-Check landen im Backlog und werden oft depriorisiert, weil sie kurzfristig keinen messbaren Umsatz bringen – bis der erste Vorfall passiert.

2. Fehlende Standardisierung in Auth-Flows
   Gängige Authentifizierungs-Bibliotheken und UI-Templates decken die klassischen Prozesse – Login, Registrierung, Passwort-vergessen – vollständig ab. Ein Status für „Passwort ist formal korrekt, aber auf einer externen Liste kompromittiert“ existiert in diesen Standard-Flows in der Regel nicht. Die Integration eines Leak-Checks erfordert daher zwingend den Bau eigener, abweichender Routing- und UX-Logiken (z. B. Intercepts im Login, Force-Reset-Redirects, spezifische Fehler-Kopien). Das sprengt die Schätzung eines standardisierten "Login implementieren"-Tickets und erfordert zusätzliche Design- und Entwicklungsressourcen.

3. Compliance-Blocker bei US-Diensten
   Wenn Teams das Problem erkennen und eine bestehende Leak-Check-API (wie z. B. etablierte US-Dienste) anbinden wollen, scheitert dies in regulierten europäischen Unternehmen oft am Veto der Datenschutzverantwortlichen. Selbst wenn Passwörter anonymisiert übertragen werden, fließen Metadaten, IP-Adressen und Zeitstempel in die USA oder durch amerikanische CDNs. Das kollidiert fundamental mit der DSGVO und dem US Cloud-Act.

4. Operativer Overhead des Eigenbetriebs
   Fällt die API-Nutzung aus Compliance-Gründen weg, bleibt nur der Eigenbetrieb. Das bedeutet: Milliarden von geleakten Datensätzen herunterladen, indizieren und eine eigene, hochverfügbare Datenbank betreiben, die bei jedem Login in unter 50 Millisekunden antwortet. Das ist massiver operativer Overhead und für kein KMU wirtschaftlich unsinnig.

Das Resultat ist die faktische Inkaufnahme des Risikos. Das Problem wird schweigend toleriert, weil die rechtssichere, einfache Lösung bisher fehlte.

Handeln statt Ignorieren

Die Zeit der Ausreden ist vorbei. Account Takeovers durch Credential Stuffing sind kein unabwendbares Schicksal, sondern ein berechenbares Risiko, für das es klare regulatorische Vorgaben von BSI und NIST gibt. Das Ausblenden dieses Risikos ist heute nicht mehr nur eine technische Nachlässigkeit, sondern ein handfestes Compliance-Problem.

Wer moderne Login-Systeme baut, muss das Verhalten der Nutzerschaft als festen Bestandteil der Sicherheitsarchitektur begreifen. Die automatisierte Prüfung gegen geleakte Passwörter ist der einzige Weg, die Lücke zwischen theoretischer Infrastruktur-Sicherheit und der Realität recycelter Zugangsdaten zu schließen.

Der Schutz davor ist keine Frage der technischen Machbarkeit mehr, sondern lediglich eine bewusste Entscheidung für mehr Sicherheit und Compliance im eigenen Login-Flow.