Credential Stuffing: Bedeutung und Schutz

Was ist Credential Stuffing?

Credential Stuffing ist ein Angriff, bei dem Bots Paare aus Benutzername und Passwort, die bei einer Website geleakt wurden, am Login-Formular einer anderen Website ausprobieren. Er funktioniert, weil Menschen Passwörter wiederverwenden. Wer bei einem gehackten Onlineshop dieselbe E-Mail-Adresse und dasselbe Passwort genutzt hat wie bei deinem Dienst, hat dem Angreifer damit einen funktionierenden Login für deinen Dienst geliefert.

Eine feste deutsche Übersetzung gibt es nicht. Wörtlich heißt Credential Stuffing etwa “Zugangsdaten stopfen”, und das beschreibt den Angriff gut: Gestohlene Zugangsdaten werden in Bot-Geschwindigkeit in fremde Login-Formulare gestopft, bis einige davon passen. Manchmal liest du auch “Credentials Stuffing”; gemeint ist derselbe Angriff.

Der Angreifer rät dabei nichts. Jedes Paar auf der Liste gehörte irgendwo zu einem echten Konto. Die meisten scheitern auf deiner Seite, weil die Person nie ein Konto bei dir hatte oder ein anderes Passwort gewählt hat. Das stört den Angreifer kaum. Die Listen sind lang, die Versuche kosten fast nichts, und ein kleiner Anteil an Treffern reicht, damit sich der Durchlauf lohnt.

Wofür die funktionierenden Konten gut sind, hängt von deinem Geschäft ab: hinterlegte Zahlungsmittel, Treuepunkte und Gutscheinguthaben, persönliche Daten für Phishing oder einfach Konten zum Weiterverkaufen. Bei einem SaaS-Produkt kann ein übernommenes Konto den ganzen Arbeitsbereich eines Kunden offenlegen. Credential Stuffing ist der automatisierte Weg zur Kontoübernahme. Welche Maßnahmen darüber hinaus helfen, steht auf unserer Seite zum Schutz vor Kontoübernahme.

So läuft ein Credential-Stuffing-Angriff ab

Ein Credential-Stuffing-Angriff hat vier Phasen, und nur eine davon spielt sich bei dir ab.

1. Eine geleakte Liste. E-Mail-Adressen oder Benutzernamen mit ihren Passwörtern, gesammelt aus Datenlecks, Phishing-Seiten und Schadsoftware, die im Browser gespeicherte Passwörter stiehlt. Sie kursieren als sogenannte Combo-Listen, oft aus vielen Datenlecks zusammengeführt und verkauft oder kostenlos geteilt.
2. Ein Tool mit einer Konfiguration für deine Seite. Der Angreifer lädt die Liste in ein Automatisierungstool und ergänzt eine Konfiguration für deinen Login: welche URL aufgerufen wird, welche Felder auszufüllen sind und woran man einen erfolgreichen Login erkennt. Konfigurationen für bekannte Seiten werden gehandelt wie die Listen selbst.
3. Bots verteilen die Versuche. Das Tool schickt die Logins über große Proxy-Pools, oft IP-Adressen privater Internetanschlüsse, sodass jede Adresse nur wenige Anfragen sendet und jedes Konto ein- oder zweimal probiert wird. Für deinen Server sieht das aus wie viele voneinander unabhängige Besucher, die sich jeweils einmal vertippt haben.
4. Aus Treffern werden Übernahmen. Logins, die funktionieren, werden gespeichert, auf ihren Wert geprüft und dann genutzt, verkauft oder gesperrt, indem der Angreifer E-Mail-Adresse und Passwort ändert, bevor der Inhaber etwas merkt.

Eine geleakte Liste kannst du nicht zurückholen, und wo deine Nutzer ihre Passwörter wiederverwenden, entscheidest du auch nicht. In Phase drei kannst du eingreifen. Jedes Paar auf der Liste muss durch dein Login-Formular oder deine Login-API, und genau dort kannst du jeden Versuch teuer machen.

Credential Stuffing vs. Brute Force

Bei einem Brute-Force-Angriff kennt der Angreifer das Passwort nicht und rät, meist mit vielen Passwörtern gegen ein Konto. Beim Credential Stuffing hat er bereits ein Passwort, das jemand wirklich benutzt hat, und probiert es einmal am passenden Konto. Dieser Unterschied entscheidet, welche Abwehr wirkt.

Die klassische Antwort auf Brute Force ist die Kontosperre: Nach einer bestimmten Zahl an Fehlversuchen wird das Konto gesperrt oder gebremst. Gegen Credential Stuffing bringt sie fast nichts, weil jedes Konto nur ein oder zwei Versuche sieht. Die Passwort-Richtlinie SP 800-63B des US-Standardisierungsinstituts NIST verlangt, aufeinanderfolgende Fehlversuche an einem Konto auf höchstens 100 zu begrenzen. Ein Credential-Stuffing-Durchlauf kommt bei keinem einzelnen Konto auch nur in die Nähe dieser Zahl.

Password Spraying liegt dazwischen: eine Handvoll gängiger Passwörter, probiert an vielen Konten. Das OWASP Credential Stuffing Prevention Cheat Sheet behandelt die drei als verwandte Angriffe und hält fest, dass die meisten Schutzmaßnahmen gegen alle drei wirken.

Für Angriffe, bei denen Passwörter geraten werden, zeigt unser Leitfaden zum Brute-Force-Schutz, wie Sperren, Verzögerungen und ein CAPTCHA zusammenspielen.

Credential Stuffing erkennen

Ein Durchlauf, der über Tausende IP-Adressen verteilt ist, löst selten einen einzelnen Alarm aus. Er zeigt sich in der Summe:

• Fehlgeschlagene Logins steigen über viele Konten gleichzeitig, während die Zahl pro Konto niedrig bleibt.
• Ein hoher Anteil der Versuche nutzt E-Mail-Adressen, zu denen es bei dir gar kein Konto gibt. Echte Nutzer tippen selten eine Adresse ein, die du noch nie gesehen hast.
• Logins kommen aus Netzen, die du sonst kaum siehst: Hosting-Anbieter, Proxy-Dienste, Länder ohne Kunden.
• Eine IP-Adresse oder ein Geräte-Fingerprint probiert viele verschiedene Konten, oder die Anfragen kommen in auffällig gleichmäßigen Abständen.
• Anfragen überspringen Teile eines normalen Besuchs: keine geladenen Seitenressourcen, fehlende Header, Spuren eines Headless-Browsers, direkte Aufrufe der Login-API.
• Danach: viele Passwort-Resets, geänderte E-Mail-Adressen und Support-Tickets zu Bestellungen, die niemand aufgegeben hat.

Credential Stuffing verhindern

Keine einzelne Maßnahme stoppt Credential Stuffing. Vier zusammen erledigen den Großteil: Multi-Faktor-Authentifizierung, damit ein gestohlenes Passwort allein nicht reicht; der Abgleich mit Datenlecks, damit die Passwörter auf den Listen der Angreifer nicht mehr funktionieren; Rate Limits, die über die IP-Adresse hinausgehen; und eine Bot-Erkennung am Login-Formular, damit jeder automatisierte Versuch etwas kostet. Das oben verlinkte OWASP Cheat Sheet beschreibt dieselben Bausteine ausführlicher.

Multi-Faktor-Authentifizierung

OWASP nennt MFA “by far the best defense against the majority of password-related attacks”, also mit Abstand den besten Schutz gegen die meisten Angriffe auf Passwörter, und verweist auf eine Analyse von Microsoft, nach der MFA 99,9 % der Kontokompromittierungen verhindert hätte. Mit einem zweiten Faktor öffnet ein korrektes Passwort aus einer geleakten Liste das Konto nicht mehr.

Trotzdem hat MFA Lücken. Sie schützt nur Konten, bei denen sie eingeschaltet ist, und auf Seiten für Endkunden schalten viele Nutzer sie nie ein. In den meisten Login-Abläufen ist der Passwort-Schritt erfolgreich, bevor der zweite Faktor abgefragt wird. Der Angreifer erfährt also weiterhin, welche Passwörter stimmen, und dieses Wissen nutzt er für Phishing oder für eine Flut von Push-Anfragen, bis ein müder Nutzer bestätigt. Außerdem landet jeder Versuch weiterhin auf deinen Servern. Ein Mittelweg ist risikobasierte MFA: Du fragst den zweiten Faktor ab, wenn ein Login ungewöhnlich wirkt, etwa von einem neuen Gerät, aus einem neuen Land oder mit hohem Bot-Score.

Rate Limits, die über die IP-Adresse hinausgehen

Ein Limit pro IP-Adresse ist der naheliegende erste Schritt, und Angreifer rechnen damit: Sie rotieren durch Proxy-Pools, sodass jede Adresse unter deinem Limit bleibt. Ergänze Limits pro Konto, pro Geräte-Fingerprint und pro Netzbereich, und beobachte die Gesamtrate fehlgeschlagener Logins. Ein plötzlicher Sprung in dieser Rate ist oft das erste Zeichen, dass ein Durchlauf begonnen hat. Langsamere Antworten nach Fehlversuchen kosten echte Nutzer wenig und Bot-Betreiber viel Zeit.

Abgleich mit geleakten Passwörtern

Prüfe neue Passwörter bei der Registrierung und bei jeder Passwortänderung gegen eine Liste von Passwörtern, die aus Datenlecks bekannt sind, und lehne die Treffer ab. NIST SP 800-63B macht das für Dienste, die der Richtlinie folgen, zur Pflicht: Neue Passwörter müssen mit einer Sperrliste abgeglichen werden, die auch Passwörter aus früheren Datenlecks enthält. Dienste wie Pwned Passwords von Have I Been Pwned erlauben den Abgleich, ohne das Passwort irgendwohin zu schicken. Du sendest nur die ersten Zeichen seines Hashwerts und vergleichst die zurückgegebenen Treffer auf deinem eigenen Server.

Derselbe Abgleich funktioniert beim Login. Meldet sich jemand mit einem Passwort an, das in einem Datenleck auftaucht, bitte ihn, es zu ändern, bevor ein Angreifer es nutzt.

Bot-Erkennung am Login-Formular

Credential Stuffing lebt von der Masse. Eine Bot-Erkennung am Login-Formular, ob über ein CAPTCHA, eine Proof-of-Work-Aufgabe oder Geräte- und Verhaltenssignale, gibt jedem Versuch einen Preis und markiert die, die automatisiert wirken. Mit einem Bot-Score kann dein Server Logins unterschiedlich behandeln: unauffällige durchlassen, zweifelhafte nach dem zweiten Faktor fragen und offensichtliche Bots abweisen.

Prüfe das Ergebnis auf dem Server bei jeder Login-Anfrage und deck jeden Zugang ab: das Webformular, die API deiner Mobile-App, ältere Login-Endpunkte, das Formular zum Zurücksetzen des Passworts und jeden Schritt, der verrät, ob es zu einer E-Mail-Adresse ein Konto gibt. Angreifer suchen sich den einen Eingang ohne Prüfung.

Kann ein CAPTCHA Credential Stuffing stoppen?

Ein CAPTCHA hilft gegen Credential Stuffing, und das gilt für jeden Anbieter: hCaptcha, Google reCAPTCHA, Cloudflare Turnstile und TrustCaptcha machen automatisierte Login-Versuche langsamer und teurer. Allein stoppt keines davon den Angriff. OWASP weist darauf hin, dass CAPTCHAs “not perfect” sind, also nicht perfekt, und dass es Tools und Dienste gibt, die sie mit recht hoher Erfolgsquote knacken. Ein Login, der am CAPTCHA vorbeikommt, funktioniert trotzdem, wenn das Passwort stimmt.

Sieh das CAPTCHA deshalb als die Schicht, die die Menge senkt, und verlass dich bei den Versuchen, die durchkommen, auf MFA und den Abgleich mit Datenlecks. Für Login-Formulare zählen bei den Anbietern vor allem drei Unterschiede: ob deine Nutzer eine Aufgabe sehen, ob du einen Score bekommst, mit dem du arbeiten kannst, und wo Besucherdaten verarbeitet werden. Dasselbe CAPTCHA an Kontakt- und Registrierungsformularen senkt auch den automatisierten Spam und hilft bei der Registrierung, die Erstellung von Fake-Accounts zu verhindern, die mit derselben Art von Automatisierung arbeitet.

Kleinere Maßnahmen, die sich summieren

• Zeig dieselbe Fehlermeldung für einen falschen Benutzernamen und ein falsches Passwort, damit dein Login Angreifern nicht verrät, zu welchen E-Mail-Adressen es ein Konto gibt.
• Benachrichtige Nutzer über Logins von neuen Geräten. Sie bemerken eine Übernahme oft früher als deine Überwachung.
• Lass Nutzer ihre aktiven Sitzungen sehen und beenden.
• Biete Passkeys an. Ein Konto, das sich mit einem Passkey anmeldet, hat kein Passwort, das geleakt und wiederverwendet werden kann.

Was tun, wenn ein Angriff läuft?

1. Erhöhe die Hürde am Login: Setz die Proof-of-Work-Schwierigkeit hoch, verlange die Bot-Prüfung bei jedem Login und blockiere die Netze, aus denen der Angriff kommt.
2. Finde die Konten mit erfolgreichen Logins von den IP-Adressen oder Geräten des Angriffs, beende ihre Sitzungen und erzwinge ein neues Passwort.
3. Sag den betroffenen Nutzern, was passiert ist und was sie tun sollten, auch dass sie das Passwort auf anderen Seiten ändern, auf denen sie es verwendet haben.
4. Kläre, ob auf personenbezogene Daten zugegriffen wurde, und frag deinen Datenschutzbeauftragten, ob der Vorfall gemeldet werden muss.
5. Prüfe danach, welchen Endpunkt der Angriff genutzt hat, und schließ diese Lücke.

TrustCaptcha an deinem Login-Formular

TrustCaptcha prüft jeden Login im Hintergrund. Das Widget startet von selbst und löst im Browser eine Proof-of-Work-Aufgabe, sodass echte Nutzer nichts lösen oder anklicken müssen, während ein Bot für jeden Versuch bezahlt. Der Proof-of-Work wird schwerer, je höher das Risiko einer Anfrage ist. Ein Durchlauf mit Tausenden Logins aus verdächtigem Traffic wird dadurch teuer.

Ab dem Solo-Tarif geben Bot-Score und eigene Proof-of-Work-Regeln deinem Server ein Signal, mit dem er arbeiten kann: den Login durchlassen, nach dem zweiten Faktor fragen oder ablehnen. TrustCaptcha setzt keine Cookies, verarbeitet Daten in EU-Rechenzentren und bietet jedem Kunden einen Auftragsverarbeitungsvertrag (AVV). Es ist eine Schicht deiner Login-Sicherheit und wirkt am besten zusammen mit MFA und dem Abgleich mit Datenlecks.

TrustCaptcha testen

Jeder Tarif startet mit einer 14-tägigen kostenlosen Testphase, und nicht-kommerzielle Websites nutzen TrustCaptcha kostenlos. Starte deine kostenlose Testphase und bring eine Prüfung an dein Login-Formular, die deine Nutzer nie lösen müssen.