Was ist Credential Stuffing? Erkennen und verhindern

Ein kleiner Onlineshop verliert seine Kundendatenbank. Wochen später registriert ein Video-Streamingdienst eine Welle von Anmeldungen bei Konten, die nie Probleme gemacht haben. Eine Gaming-Plattform erlebt dasselbe, ebenso eine Bank. Keiner dieser Dienste wurde gehackt. Die E-Mail-Passwort-Paare aus dem Shop funktionierten einfach auch auf ihren Login-Seiten, weil viele Menschen überall dasselbe Passwort verwenden.

Dieser Beitrag betrachtet Credential Stuffing aus Sicht der Verteidigung: wie es sich von Brute-Force-Angriffen und Password Spraying unterscheidet, warum es über Tausende IP-Adressen kommt, welche Signale es in Ihren Logs hinterlässt, welche Maßnahmen es stoppen und was Nutzer selbst tun können. Dazu gibt es zwei kurze Python-Beispiele, beide rein defensiv.

Was ist Credential Stuffing?#

Credential Stuffing ist die massenhafte Wiederverwendung gestohlener Zugangsdaten. Der Angreifer beginnt mit Paaren, von denen bekannt ist, dass sie echt sind, weil sie aus einem früheren Datenleck eines anderen Dienstes stammen, und schickt sie mit einer Software automatisiert an ein Login-Formular. Die meisten Paare scheitern. Erfolgreich sind die Konten, deren Inhaber auf der gehackten Website und auf dem Ziel dasselbe Passwort genutzt haben.

Das OWASP Credential Stuffing Prevention Cheat Sheet definiert den Angriff als das Testen von Benutzername-Passwort-Paaren, die „aus dem Datenleck einer anderen Website stammen“. Die Passwörter der Zielseite selbst wurden nicht gestohlen, und ihr Code hat keinen Fehler; die Schwachstelle ist die Wiederverwendung von Passwörtern.

Das Ziel des Angreifers ist die Kontoübernahme (Account Takeover, ATO): ein funktionierender Zugang zu einem Konto, das einen Wert hat. Das können Treuepunkte sein, eine hinterlegte Zahlungskarte, Guthaben auf Geschenkkarten, persönliche Daten oder einfach ein vertrauenswürdiges Konto, über das sich Spam verschicken lässt. Übernommene Konten werden häufig weiterverkauft.

Wie läuft ein Credential-Stuffing-Angriff ab?#

Grob betrachtet durchläuft ein Angriff fünf Phasen. Wer sie kennt, kann besser entscheiden, wo welche Abwehrmaßnahme ansetzt.

1. Ein Datenleck anderswo. Ein Dienst wird kompromittiert, und seine Nutzerliste mit E-Mail-Adressen und Passwörtern (oder Passwort-Hashes, die später geknackt werden) gerät in Umlauf.
2. Sammeln. Geleakte Paare aus vielen Datenlecks werden zu großen Listen zusammengeführt. Alte Leaks bleiben jahrelang wertvoll, weil viele Menschen ein wiederverwendetes Passwort nie ändern.
3. Automatisierung. Eine Software schickt die Paare an das Login-Formular oder die Login-API des Ziels, weit schneller, als ein Mensch tippen könnte.
4. Verteilung. Um einfache Limits pro IP zu umgehen, werden die Anfragen auf viele IP-Adressen verteilt, oft über Botnetze aus infizierten Geräten oder gemietete Proxy-Netzwerke, sodass jede Adresse nur wenige Versuche sendet.
5. Verwertung der Treffer. Funktionierende Paare werden auf ihren Wert geprüft und dann genutzt oder verkauft. Manche Angreifer ändern sofort E-Mail-Adresse und Passwort, um den echten Inhaber auszusperren.

Phase 1 findet auf dem Server eines anderen statt. Ihre Abwehr setzt bei den Phasen 3 bis 5 an: automatisierte Logins teuer machen, ein korrektes Passwort allein nicht ausreichen lassen und eine Übernahme früh bemerken. Der Abgleich von Passwörtern mit Leak-Listen dreht Phase 2 gegen den Angreifer.

Credential Stuffing vs. Brute Force vs. Password Spraying#

Alle drei Angriffe zielen auf Login-Seiten, nutzen aber unterschiedliche Eingaben und hinterlassen unterschiedliche Spuren. Die Definitionen folgen dem OWASP Cheat Sheet.

Eine Kontosperre nach fünf falschen Passwörtern stoppt Brute Force. Credential Stuffing berührt sie kaum, weil jedes Konto meist nur einen einzigen Versuch sieht.

Warum Proxys und Residential-IPs bei diesen Angriffen auftauchen#

Eine IP-Adresse nach zwanzig fehlgeschlagenen Logins zu sperren, wirkt wie Schutz. Deshalb leiten Angreifer ihre Anfragen über viele Adressen: gekaperte Heimrouter, infizierte Geräte, Cloud-Server und Proxy-Netzwerke. Adressen von Privatanschlüssen lassen sich schwer sperren, weil echte Kunden sie ebenfalls nutzen können.

Deshalb heißt es im OWASP Cheat Sheet, IP-Sperren und IP-Reputation sollten „nicht als einzige oder primäre Abwehr“ eingesetzt werden. In der Praxis gibt es drei Probleme:

• Geringes Volumen pro Adresse. Wenn jede Adresse nur ein oder zwei Versuche sendet, greift kein Schwellenwert pro IP.
• Geteilte Adressen. Mobilfunkanbieter und viele Internetanbieter für Privatkunden setzen zahlreiche Kunden hinter eine öffentliche Adresse (Carrier-Grade NAT). Wer diese Adresse sperrt, kann echte Nutzer aussperren.
• Schneller Wechsel. Die Adressen ändern sich rasch, sodass eine Sperrliste fast schon beim Schreiben veraltet ist.

IP-Daten bleiben trotzdem nützlich, als ein Signal unter mehreren. Ein IP Fraud Score oder ein Eintrag auf einer IP-Blacklist kann das Risiko eines Logins erhöhen und eine zusätzliche Prüfung auslösen, statt ihn sofort zu blockieren.

Ein Hinweis zu unserem eigenen Netzwerk: Die Nutzungsbedingungen von Proxynet verbieten Versuche unbefugten Zugriffs, und Konten, die gegen die Regeln zur zulässigen Nutzung verstoßen, können ohne Vorankündigung gesperrt werden. Legitime Einsätze wie das Testen Ihrer eigenen Website aus anderen Ländern beschreiben wir auf unserer Seite zur Datensicherheit.

Signale, dass Sie angegriffen werden#

Kein einzelnes Signal beweist einen Angriff, aber mehrere zusammen sind kaum zu übersehen. Diese gehören auf ein Dashboard:

• Ein Sprung bei der Fehlerquote der Logins. Die meisten geleakten Paare passen nicht, deshalb treibt eine Angriffswelle eine sonst stabile Quote steil nach oben.
• Viele Fehler vom Typ „unbekannter Nutzer“. Geleakte Listen enthalten E-Mail-Adressen, die bei Ihnen nie registriert waren.
• Viele Konten, je ein Versuch. Das Verhältnis von unterschiedlichen Benutzernamen zu Versuchen liegt nahe eins, das Gegenteil des Brute-Force-Musters.
• Viele IP-Adressen mit jeweils wenigen Versuchen, oft aus Netzen, aus denen sonst kaum echte Nutzer kommen.
• Identische Client-Fingerprints bei Tausenden „verschiedener“ Nutzer; wie Bot-Erkennung funktioniert erklärt diese Signale.
• Logins ohne Seitenaufruf. Anfragen, die direkt an die Login-API gehen, ohne die Login-Seite, ihre Skripte oder Bilder zu laden.
• Was nach dem Erfolg passiert. Ein Login, auf den innerhalb von Sekunden eine Änderung von E-Mail-Adresse, Passwort oder Auszahlungsdaten folgt.

Oft bemerken Nutzer es vor Ihnen: eine Warnung der Bank vor einer verdächtigen Anmeldung oder eine E-Mail zu einer „neuen Anmeldung“, die sie nicht selbst ausgelöst haben. Machen Sie es ihnen leicht, das zu melden.

Wie Sie Credential Stuffing auf Ihrer Website verhindern#

Das OWASP Cheat Sheet ordnet die Abwehrmaßnahmen grob nach ihrem Nutzen. Die folgende Liste behält diesen Ansatz bei und ergänzt, was NIST SP 800-63B (Revision 4, seit August 2025 final) von Passwortsystemen verlangt.

1. Multi-Faktor-Authentifizierung (MFA). OWASP bezeichnet MFA als „mit Abstand die beste Abwehr“ gegen Passwortangriffe: Ein korrektes geleaktes Passwort reicht dann nicht mehr. Schreiben Sie sie für Admin-Konten und riskante Aktionen vor und fordern Sie sie an, wenn die oben genannten Signale anschlagen.
2. Passkeys. Ein Passkey ersetzt das Passwort durch ein Schlüsselpaar, das auf dem Gerät des Nutzers liegt. Die FIDO Alliance beschreibt Passkeys als phishing-resistent, und auf Ihrem Server liegt kein gemeinsames Geheimnis, das geleakt oder wiederverwendet werden könnte. Ein Konto, das sich nur per Passkey anmeldet, bietet Credential Stuffing nichts zum Ausprobieren.
3. Prüfung auf geleakte Passwörter. Nach Abschnitt 3.1.1.2 von NIST SP 800-63B müssen Verifier ein neues Passwort mit einer Sperrliste „häufig verwendeter, erwartbarer oder kompromittierter“ Werte abgleichen. Prüfen Sie bei der Registrierung und bei jeder Passwortänderung, und erzwingen Sie eine Änderung, wenn es Hinweise auf eine Kompromittierung gibt.
4. Versuchslimits, die dem Konto folgen, nicht nur der IP. NIST-Abschnitt 3.2.2 begrenzt aufeinanderfolgende Fehlversuche bei einem Konto auf höchstens 100. Kombinieren Sie das mit Limits pro Gerät, pro IP-Bereich und pro Login-Endpunkt, und verlangsamen Sie die Antworten schrittweise, statt Konten zu sperren.
5. Bot-Management. Prüfen Sie, ob der Client JavaScript ausführt und ob sein Verbindungs-Fingerprint zum angegebenen Browser passt. Ein CAPTCHA ist eine Bremsschwelle, nicht die ganze Abwehr.
6. Dieselbe Antwort bei jedem Fehler. Geben Sie bei „falsches Passwort“ und „Nutzer existiert nicht“ dieselbe Meldung mit ähnlichem Timing zurück, damit sich über das Login-Formular nicht prüfen lässt, zu welchen E-Mail-Adressen Konten existieren.
7. Nutzer benachrichtigen und das Konto nach dem Login beobachten. Warnen Sie bei Anmeldungen von neuen Geräten und bei Kontoänderungen, und verlangen Sie vor solchen Änderungen einen zweiten Faktor.

Code: Prüfung auf geleakte Passwörter mit k-Anonymität#

Die Pwned Passwords API von Have I Been Pwned prüft ein Passwort gegen bekannte Datenlecks, ohne dass Sie das Passwort oder auch nur seinen vollständigen Hash senden. Sie übermitteln nur die ersten fünf Zeichen des SHA-1-Hashes; der Dienst liefert alle Hash-Suffixe, die damit beginnen, jeweils mit einer Häufigkeit, und Sie suchen Ihr Suffix lokal. Das ist das Modell der k-Anonymität (k-anonymity). Die Range-API braucht keinen API-Schlüssel, und der Header Add-Padding fügt Scheinzeilen (Anzahl 0) hinzu, damit die Größe der Antwort nichts verrät.

import hashlib
import time
import urllib.error
import urllib.request

API = "https://api.pwnedpasswords.com/range/"


def breach_count(password: str, retries: int = 3) -> int:
    """Gibt zurück, wie oft ein Passwort in Pwned Passwords vorkommt (0 = nicht gefunden)."""
    digest = hashlib.sha1(password.encode("utf-8")).hexdigest().upper()
    prefix, suffix = digest[:5], digest[5:]
    request = urllib.request.Request(
        API + prefix,
        headers={"User-Agent": "example-signup-check", "Add-Padding": "true"},
    )
    for attempt in range(retries):
        try:
            with urllib.request.urlopen(request, timeout=5) as response:
                body = response.read().decode("utf-8")
            break
        except (urllib.error.URLError, TimeoutError):
            if attempt == retries - 1:
                raise
            time.sleep(2 ** attempt)
    for line in body.splitlines():
        candidate, _, count = line.partition(":")
        if candidate == suffix:
            return int(count)  # Padding-Zeilen haben die Anzahl 0
    return 0


if __name__ == "__main__":
    for pw in ["password123", "correct horse battery staple", "vX9#qL2-mT8!rW4zK7"]:
        hits = breach_count(pw)
        verdict = "reject: seen in breaches" if hits else "not in the breach list"
        print(f"{pw!r}: {hits} -> {verdict}")

Führen Sie das Skript aus, werden die ersten beiden Passwörter als gefunden gemeldet, mit Zahlen, die mit jeder Aktualisierung des Datensatzes steigen; die Zufallszeichenfolge liefert 0. In einem Registrierungsformular rufen Sie breach_count auf dem Server auf, lehnen jedes Ergebnis ungleich null mit einer klaren Meldung ab und legen vorab fest, was passiert, wenn die API nicht erreichbar ist.

Code: eine Stuffing-Welle in Login-Logs erkennen#

Die meisten Websites protokollieren jeden Login-Versuch ohnehin. Das folgende Skript liest ein CSV-Log mit den Spalten time, ip, username und result, gruppiert die Versuche nach Minuten und gibt die Minuten mit auffälliger Fehlerquote aus, zusammen mit dem Anteil unbekannter Benutzernamen und der Zahl unterschiedlicher Konten und Adressen.

import csv
from collections import defaultdict

ALERT_FAIL_RATE = 0.50
MIN_ATTEMPTS = 50

# Login-Versuche in Ein-Minuten-Buckets gruppieren.
buckets = defaultdict(lambda: {"total": 0, "failed": 0, "unknown": 0, "users": set(), "ips": set()})
with open("logins.csv", newline="") as f:
    for row in csv.DictReader(f):
        b = buckets[row["time"][:16]]          # "2026-09-28T10:41"
        b["total"] += 1
        b["users"].add(row["username"])
        b["ips"].add(row["ip"])
        if row["result"] != "ok":
            b["failed"] += 1
        if row["result"] == "unknown_user":
            b["unknown"] += 1

for minute in sorted(buckets):
    b = buckets[minute]
    fail_rate = b["failed"] / b["total"]
    unknown_share = b["unknown"] / b["total"]
    if b["total"] >= MIN_ATTEMPTS and fail_rate >= ALERT_FAIL_RATE:
        print(f"{minute}  attempts={b['total']}  failed={fail_rate:.0%}  "
              f"unknown-user={unknown_share:.0%}  accounts={len(b['users'])}  ips={len(b['ips'])}")

Auf einem Test-Log mit normalem Traffic und einer simulierten Angriffswelle sieht die Ausgabe so aus:

2026-09-28T10:40  attempts=80  failed=78%  unknown-user=49%  accounts=80  ips=69
2026-09-28T10:41  attempts=80  failed=79%  unknown-user=45%  accounts=80  ips=70

Achtzig Konten, fast ebenso viele Adressen und die Hälfte der Benutzernamen unbekannt: das typische Stuffing-Muster. Legen Sie die Schwellenwerte anhand Ihres eigenen normalen Traffics fest.

Was Nutzer tun können#

Credential Stuffing funktioniert nur bei wiederverwendeten Passwörtern, Nutzer haben es also tatsächlich selbst in der Hand.

• Nutzen Sie einen Passwortmanager, damit jede Website ein eigenes zufälliges Passwort bekommt.
• Aktivieren Sie die Zwei-Faktor-Authentifizierung, zuerst für E-Mail und Onlinebanking; eine Authenticator-App oder ein Sicherheitsschlüssel ist besser als SMS-Codes.
• Wechseln Sie zu Passkeys, wo eine Website sie unterstützt. Dann gibt es kein Passwort mehr, das geleakt oder wiederverwendet werden kann.
• Prüfen Sie Ihre E-Mail-Adresse bei Have I Been Pwned und ändern Sie jedes Passwort, das Sie mehrfach verwendet haben.
• Reagieren Sie auf Hinweise zu „neuen Anmeldungen“, die Sie nicht selbst ausgelöst haben: Passwort ändern und andere Sitzungen abmelden.
• Melden Sie sich nicht über unbekannte Netzwerke an. Ein kostenloser Proxy, den ein Fremder betreibt, kann Ihren Traffic mitlesen; siehe Sind kostenlose Proxys und Web-Proxy-Seiten sicher?.

Wo das besonders wichtig ist#

• Onlineshops und Marktplätze. Hinterlegte Karten, Geschenkkarten und Treuepunkte machen Konten zu lohnenden Zielen; auf unserer Seite zu E-Commerce lesen Sie, wie Shops ihre eigenen Storefronts testen.
• Banken und Fintechs. Eine Kontoübernahme führt direkt zu Geldbewegungen; die Seite Finanzen zeigt, wie Finanzteams ihre öffentlichen Seiten aus anderen Regionen prüfen.
• Streaming und Gaming. Geteilte und weiterverkaufte Konten sind ein beständiger Markt für gestohlene Logins.
• Jede Website, die personenbezogene Daten erhebt. Eine Übernahme legt die gespeicherten Daten des Nutzers offen, was ein Datenschutzproblem ebenso ist wie ein Betrugsproblem; den Umgang mit solchen Daten für Datenteams behandelt unser Beitrag zu personenbezogenen Daten in Scraping-Datensätzen.

Häufige Fehler#

• Sich auf IP-Sperren verlassen. Gegen verteilte Angriffe versagen sie.
• Konten nach wenigen Fehlversuchen sperren. Damit können Angreifer Ihre Kunden aussperren.
• Unterschiedliche Fehlermeldungen für „falsches Passwort“ und „Konto existiert nicht“. So wird Ihr Login-Formular zu einem kostenlosen E-Mail-Prüfdienst.
• Das Webformular schützen, die API aber nicht. Mobile Apps und alte API-Versionen haben oft einen eigenen Login-Endpunkt mit schwächeren Limits.
• Regelmäßige Passwortwechsel erzwingen. NIST SP 800-63B rät davon ab; erzwingen Sie einen Wechsel nur bei Hinweisen auf eine Kompromittierung.
• Nur den Login beobachten. Eine Übernahme zeigt sich am deutlichsten in dem, was danach passiert.

Entscheidungshilfe#

Häufige Fragen#

Ist Credential Stuffing illegal?#

Ja. Sich ohne Erlaubnis in das Konto eines anderen einzuloggen, gilt in den meisten Ländern nach den Gesetzen gegen Computerkriminalität als unbefugter Zugriff, unabhängig vom verwendeten Werkzeug. Tests sind nur auf Systemen zulässig, die Ihnen gehören oder für die Sie eine schriftliche Testerlaubnis haben.

Worin unterscheidet sich Credential Stuffing von einem Datenleck?#

Ein Datenleck ist der Diebstahl von Daten bei einem Dienst. Credential Stuffing folgt danach, wenn die gestohlenen Paare bei anderen Diensten ausprobiert werden. Die angegriffene Website selbst wurde womöglich nie gehackt.

Stoppt ein CAPTCHA Credential Stuffing?#

Es bremst den Angriff und erhöht seine Kosten, ist aber keine vollständige Abwehr. OWASP führt es als eine von mehreren Schichten, nach der Multi-Faktor-Authentifizierung.

Warum nicht einfach ein Konto nach drei falschen Passwörtern sperren?#

Beim Credential Stuffing erhält jedes Konto meist nur einen einzigen Versuch, die Sperre greift also selten. Wo sie greift, lässt sie sich missbrauchen, um echte Nutzer auszusperren. Limits, die über Konto, Gerät und Endpunkt verteilt sind, wirken besser.

Ist der Abgleich mit Pwned Passwords für meine Nutzer sicher?#

Mit der Range-API senden Sie nur die ersten fünf Zeichen des SHA-1-Hashes des Passworts, der Abgleich findet auf Ihrem Server statt. Der Dienst sieht weder das vollständige Passwort noch den vollständigen Hash.

Beenden Passkeys das Credential Stuffing?#

Für Konten, die sich nur per Passkey anmelden, ja: Es gibt kein wiederverwendbares Passwort zum Ausprobieren. Solange eine Website Passwörter noch als Ausweichweg akzeptiert, braucht dieser Ausweichweg denselben Schutz.

Fazit#

Credential Stuffing macht aus dem Datenleck einer Website Kontoübernahmen bei vielen anderen, weil Menschen Passwörter wiederverwenden. Der Angriff ist auf viele IP-Adressen verteilt, IP-Sperren allein halten ihn deshalb nicht auf. Wirksam sind Multi-Faktor-Authentifizierung oder Passkeys, das Ablehnen von Passwörtern aus Leak-Listen, wie es NIST SP 800-63B verlangt, Versuchslimits pro Konto und Gerät, Bot-Erkennung und der Blick darauf, was nach einem Login passiert. Nutzer schließen die Tür auf ihrer Seite mit einem Passwortmanager und eigenen Passwörtern für jedes Konto. Für legitime Tests Ihrer eigenen Login-Abläufe und Seiten aus anderen Regionen finden Sie unsere Proxy-Dienste und Residential-Proxy.