Brute Force und Credential Stuffing

Jedes Anmeldeformular, das aus dem Internet erreichbar ist, bekommt täglich Besuch von automatisierten Skripten. Sie raten Passwörter oder senden E-Mail-Adressen und Passwörter, die bei einem anderen Unternehmen abgeflossen sind. Solange Ihre Anwendung beliebig viele Versuche annimmt, ist der Zugang vor allem eine Frage von Zeit und Bandbreite. Dieser Artikel zeigt, wie beide Angriffe ablaufen und welche Maßnahmen sie unwirtschaftlich machen.

Was sind Brute Force und Credential Stuffing?

Von Brute Force spricht man, wenn jemand Zugangsdaten systematisch durchprobiert, bis eine Kombination passt, weil die Anwendung die Zahl der Versuche nicht begrenzt. Credential Stuffing ist die wirksamere Spielart: Der Angreifer rät nicht, sondern spielt Paare aus E-Mail-Adresse und Passwort ein, die bei einem anderen Unternehmen entwendet wurden, in dem Wissen, dass ein Teil Ihrer Nutzer dasselbe Passwort überall verwendet. Im CWE-Katalog heißt die zugrunde liegende Schwäche unzureichende Beschränkung übermäßiger Anmeldeversuche, CWE-307.

Ein Vergleich aus dem Alltag: Ein Einbrecher, der jeden Schlüssel eines großen Bundes an Ihrer Haustür probiert, führt einen Brute-Force-Angriff. Ein Einbrecher, der den Schlüssel Ihres Fahrradschuppens gefunden hat und ihn ohne weitere Überlegung an der Haustür probiert, betreibt Credential Stuffing. Der zweite braucht weit weniger Versuche, denn er beginnt mit einem Schlüssel, der nachweislich zu Ihnen gehört.

Dazwischen liegt das Password Spraying. Der Angreifer wählt ein verbreitetes Passwort, etwa eine Jahreszeit gefolgt von der Jahreszahl, und probiert es gleichzeitig auf Tausenden Konten. Je Konto bleibt es bei einem einzigen Versuch, sodass ein Zähler, der nur ein Konto betrachtet, nichts Auffälliges bemerkt. Genau deshalb ist eine Sperre nach fünf Fehlversuchen auf einem Konto gegen diese Spielart wirkungslos.

Steht ein zweiter Faktor im Weg, geht der Angriff einen Schritt weiter. MFA steht für Multi-Faktor-Authentifizierung: Neben dem Passwort wird ein zweiter Nachweis verlangt, etwa ein Code oder ein Hardwareschlüssel. Bei einem MFA-Fatigue-Angriff besitzt der Angreifer das Passwort bereits und schickt so lange Push-Anfragen, bis der Nutzer eine davon aus Gewohnheit oder Verdruss bestätigt.

Wie läuft ein Brute-Force- oder Credential-Stuffing-Angriff ab?

Nehmen Sie ein gewöhnliches Anmeldeformular. Die Anwendung sucht den Nutzer, vergleicht das Passwort und setzt bei Erfolg eine Sitzung. Es gibt keinen Zähler, keine Verzögerung und keine Grenze je Quelle.

Verwundbar:

app.post("/anmelden", async (req, res) => {
  const { email, passwort } = req.body;

  const nutzer = await db.nutzer.findeNachEmail(email);
  if (!nutzer) {
    // Zwei verschiedene Meldungen verraten, welche Adressen es gibt
    return res.status(401).send("Unbekannte E-Mail-Adresse");
  }

  if (await bcrypt.compare(passwort, nutzer.passwortHash)) {
    req.session.nutzerId = nutzer.id;
    return res.redirect("/uebersicht");
  }

  // Kein Zähler, keine Verzögerung, keine Grenze je Quelle
  return res.status(401).send("Falsches Passwort");
});

Der Angreifer schneidet eine erfolgreiche Anfrage aus dem eigenen Browser mit und wiederholt sie mit einer Liste. Beim Credential Stuffing stammt diese Liste aus einer öffentlichen Sammlung geleakter Paare, beim Spraying ist es ein Passwort gegen viele Adressen.

POST /anmelden HTTP/1.1
Host: app.beispiel.de
Content-Type: application/x-www-form-urlencoded

email=j.walter@firma.de&passwort=Sommer2026!

Eine solche Anfrage kostet wenige Millisekunden. Mit tausend gleichzeitigen Verbindungen über Wohnadress-Proxys sind Hunderttausende Kombinationen je Stunde erreichbar, verteilt auf so viele IP-Adressen, dass keine einzelne auffällt. Die zwei unterschiedlichen Fehlermeldungen helfen dabei: “Unbekannte E-Mail-Adresse” bestätigt, welche Adressen es nicht gibt, sodass die Liste erst bereinigt und dann durchprobiert wird. Diese Nebenwirkung ist ein eigener Befund, siehe Username Enumeration.

Die sichere Fassung tut vier Dinge zugleich. Sie zählt Versuche je Konto und je Quelle, sie gibt in beiden Fällen dieselbe Fehlermeldung zurück, sie wendet für eine unbekannte Adresse denselben Rechenaufwand auf wie für eine echte, und sie behandelt das Passwort als ersten von zwei Schritten.

Sicher:

const MAX_JE_KONTO  = 5;    // je 15 Minuten
const MAX_JE_QUELLE = 50;   // je 15 Minuten, je IP-Adresse

app.post("/anmelden", async (req, res) => {
  const { email, passwort } = req.body;
  const konto  = "konto:"  + normalisiereEmail(email);
  const quelle = "quelle:" + clientIp(req);

  // Zwei unabhängige Zähler in einem gemeinsamen Speicher
  if (await ueberGrenze(konto, MAX_JE_KONTO, 900) ||
      await ueberGrenze(quelle, MAX_JE_QUELLE, 900)) {
    return res.status(429).send("Zu viele Versuche. Bitte später erneut.");
  }

  const nutzer = await db.nutzer.findeNachEmail(email);

  // Immer hashen, auch ohne Treffer: gleiche Antwortzeit
  const hash = nutzer ? nutzer.passwortHash : DUMMY_HASH;
  const ok = (await bcrypt.compare(passwort, hash)) && Boolean(nutzer);

  if (!ok) {
    await zaehleFehlversuch(konto, quelle);
    // Eine Meldung für beide Fälle
    return res.status(401).send("E-Mail-Adresse oder Passwort ist falsch.");
  }

  await setzeFehlversucheZurueck(konto);

  // Das Passwort stimmt; die Identität steht erst nach dem zweiten Faktor fest
  req.session.offeneNutzerId = nutzer.id;
  return res.redirect("/anmelden/mfa");
});

Der Zähler je Konto bremst das Raten gegen ein einzelnes Opfer. Der Zähler je Quelle bremst das Spraying, das seine Versuche bewusst über viele Konten streut und je Konto unsichtbar bleibt. Sie brauchen beide: Jeder Zähler deckt genau den Angriff ab, den der andere durchlässt. Halten Sie die Zähler in einem zentralen Speicher wie Redis, sonst zählt jeder Anwendungsserver seinen eigenen Anteil und die tatsächliche Grenze ist ein Vielfaches der eingestellten.

Welche Auswirkungen haben Brute Force und Credential Stuffing?

Ein einziges übernommenes Konto gibt dem Angreifer alles, was dieser Nutzer sehen und tun darf: personenbezogene Daten, Bestellungen, Rechnungen, interne Unterlagen. Von dort folgt meist eine zweite Stufe, denn Nachrichten von innen werden selten hinterfragt. Gehört das Konto einer Administratorin oder einem Servicemitarbeiter, der Passwörter zurücksetzen kann, reicht der Schaden bis zur gesamten Plattform.

Wirtschaftlich bedeutet das Betrug und Rückbuchungen, Missbrauch hinterlegter Zahlungsdaten, Diebstahl von Bonuspunkten oder Guthaben sowie eine mögliche Meldepflicht nach der DSGVO, sobald personenbezogene Daten eingesehen wurden. Auch der Angriff selbst kostet Kapazität: Eine große Credential-Stuffing-Welle kann Anmeldedienste und Servicedesks lahmlegen, ohne dass ein einziger Versuch erfolgreich ist.

Weil der Schweregrad davon abhängt, welches Konto fällt und was dahintersteht, reicht die Einstufung von mittel bis hoch. Ein Kundenkonto mit wenigen Daten und verpflichtender MFA bleibt beherrschbar. Ein System ohne zweiten Faktor, in dem dasselbe Passwort auch das VPN oder das Postfach öffnet, steht am oberen Ende.

Wie spürt man Brute Force und Credential Stuffing auf?

In den Protokolldateien ist das Muster erkennbar: ein Verhältnis von fehlgeschlagenen zu erfolgreichen Anmeldungen, das plötzlich kippt, viele verschiedene Benutzernamen aus einer Quelle oder umgekehrt ein einziger Passwortversuch je Konto, verteilt über Hunderte Quellen. Achten Sie zudem auf gleichförmige User-Agent-Angaben, ungewöhnliche Uhrzeiten und einen Anstieg von Passwortzurücksetzungen kurz nach einem bekannt gewordenen Leak anderswo.

Ein Tester fragt zuerst, ob es überhaupt eine Grenze gibt, und dann, ob sie sich umgehen lässt. Die klassischen Lücken: Der Zähler hängt am Sitzungscookie und verschwindet, sobald man dieses verwirft, die Anwendung vertraut dem Header X-Forwarded-For und der Angreifer füllt ihn selbst aus, oder das Webformular ist begrenzt, während /api/anmelden, die mobile Schnittstelle und ein Altprotokoll wie IMAP unbegrenzt laufen. Vergessen Sie die umliegenden Endpunkte nicht: Passwort vergessen, Prüfung des Einmalcodes und Registrierung verraten oft, ob eine Adresse existiert, und ein sechsstelliger Code ohne Grenze ist in Minuten erschöpft.

Scanner beobachten nur, ob eine Folge schneller Versuche auf dem Hauptweg blockiert wird. Ob die Grenze auch einem verteilten, langsamen Angriff und jedem Nebenweg standhält, zeigt sich erst in Handarbeit. AssistSec prüft dies im Rahmen eines Penetrationstests, einschließlich des Verhaltens des zweiten Faktors und der Fehlermeldungen rund um Benutzernamen.

Wie verhindert man Brute Force und Credential Stuffing?

• Begrenzen Sie Versuche je Konto und je Quelle. Arbeiten Sie mit steigender Verzögerung und vorübergehender Blockade statt mit einer harten Sperre, und halten Sie die Zähler in einem gemeinsamen Speicher, damit sie über alle Server hinweg gelten.
• Schalten Sie MFA standardmäßig ein, nicht nur für Administratoren. Bevorzugen Sie Passkeys oder einen Hardwareschlüssel; setzen Sie bei Push-Anfragen den Nummernabgleich ein und begrenzen Sie deren Zahl.
• Gleichen Sie neue Passwörter gegen bekannte Leaks ab. Vergleichen Sie lokal gegen eine Liste geleakter Hashwerte oder nutzen Sie eine Bereichsabfrage über die ersten fünf Zeichen des Hashwerts, damit das Passwort Ihre Umgebung nie verlässt.
• Geben Sie dieselbe Fehlermeldung und dieselbe Antwortzeit zurück. Anmeldung, Passwortwiederherstellung und Registrierung dürfen nie verraten, ob eine E-Mail-Adresse bekannt ist.
• Schützen Sie jeden Eingang. Schnittstellen, mobile Clients, Altprotokolle, Passwortwiederherstellung und die Prüfung von Einmalcodes brauchen dieselben Grenzen wie das Webformular.
• Protokollieren und alarmieren Sie auf Muster, nicht auf Einzelversuche. Messen Sie das Verhältnis fehlgeschlagener zu erfolgreichen Anmeldungen je Minute und benachrichtigen Sie Nutzer über eine Anmeldung von einem neuen Gerät oder Ort.
• Setzen Sie verdächtigem Verkehr eine zweite Hürde vor. Ein CAPTCHA oder ein Rechennachweis nach mehreren Fehlversuchen trifft automatisierten Verkehr hart und gewöhnliche Nutzer kaum.