Kontoübernahme und Credential Stuffing im Shop abwehren

Eine Kontoübernahme beginnt selten mit einem Einbruch in die Datenbank. Sie beginnt mit gewöhnlichen Anmeldeversuchen: Zugangsdaten, die beim Einbruch in einen anderen Dienst abgeflossen sind, werden gegen die eigene Anmeldemaske durchprobiert (OWASP). Die meisten scheitern, einige gelingen, und im Protokoll steht zunächst nichts als etwas mehr Verkehr auf einer einzigen Adresse. Vor der Hochsaison wird daraus ein betriebliches Problem, weil derselbe Verkehr dieselben Warteschlangen belegt wie die Kasse. Dieser Beitrag beschreibt die Abwehrkette Stufe für Stufe: eine Ratenbegrenzung, die nicht nur nach IP-Adresse zählt, Passwortregeln nach den aktuellen NIST-Richtlinien, den zweiten Faktor an der richtigen Stelle und den Reaktionsweg für den Fall, dass ein Konto tatsächlich übernommen wurde. Die Grundlage dafür ist ein Betrieb, der mitzählt.

Credential Stuffing ist kein Passwortraten

Die beiden Begriffe werden im Alltag vermischt, im Betrieb verhalten sie sich unterschiedlich. Beim Passwortraten probiert ein Angreifer viele Passwörter gegen ein Konto. Beim Credential Stuffing probiert er ein Paar aus Nutzername und Passwort gegen viele Konten – Paare, die aus dem Einbruch bei einem anderen Dienst stammen (OWASP). Das OWASP-Projekt Automated Threats to Web Applications führt das Verfahren als eigene automatisierte Bedrohung unter der Kennung OAT-008: anderswo gestohlene Zugangsdaten werden gegen die Anmeldung einer Anwendung durchprobiert, um wiederverwendete Zugangsdaten zu finden (OWASP). Für die Abwehr ist der Unterschied entscheidend. Gegen Passwortraten hilft eine Obergrenze für Fehlversuche je Konto. Gegen Credential Stuffing hilft sie nur mit, denn je Konto bleibt es oft bei einem einzigen Versuch – auffällig ist nicht das Konto, sondern die Verteilung über viele Konten hinweg.

Warum sich das Durchprobieren überhaupt lohnt, zeigt eine Auswertung geleakter Datensätze. Untersucht wurden 28,8 Millionen Personen und ihre 61,5 Millionen Passwörter über 107 Onlinedienste (Virginia Tech). Von den Personen, die mit mindestens zwei Klartextpasswörtern in diesen zwischen 2008 und 2016 geleakten Datensätzen auftauchen, verwendeten 38 Prozent dasselbe Passwort bei mehreren Diensten, weitere 20 Prozent wandelten ein bestehendes Passwort ab (Virginia Tech). Gezählt sind dabei Personen, nicht Konten: Dieselbe Person kann in mehreren Leaks stecken.

We find that 38% of the users have reused exactly the same password across different sites, while 20% have modified an existing password to create new ones.

Wang, Jan, Hu, Wang: Empirical Analysis of Password Reuse and Modification across Online Service (Virginia Tech)

Der zweite Befund derselben Arbeit erklärt, warum eine Begrenzung der Fehlversuche überhaupt etwas ausrichtet. Mit einem eigens gebauten Ratealgorithmus ließen sich mehr als 16 Millionen Passwortpaare innerhalb von zehn Versuchen knacken (Virginia Tech). Wer ein Passwort einer Person kennt, braucht für das zweite oft nur wenige Anläufe, weil die Abwandlung Mustern folgt: eine Ziffer hinten dran, ein Sonderzeichen ersetzt, der Dienstname eingebaut. Genau dort setzt eine Grenze an. Eine Grenze nach einer überschaubaren Zahl von Fehlversuchen erschwert das Durchprobieren vieler Abwandlungen, fängt aber nicht alles ab: In derselben Arbeit fielen alle wiederverwendeten und 30 Prozent der abgewandelten Passwörter bereits innerhalb von zehn Versuchen. Die Werte stammen allerdings aus Leaks der Jahre 2008 bis 2016 und beschreiben ein Rateverfahren auf Leak-Daten, keinen gemessenen Angriff auf eine laufende Anmeldung.

Die Lage in Deutschland: was gemeldet wird

Für Deutschland führen mehrere Erhebungen Zahlen, die für Anmeldewellen unmittelbar von Belang sind. Im Berichtszeitraum des BSI-Lageberichts 2025 wurden 461 Datenleaks mit Daten von Institutionen sowie von deutschen Verbraucherinnen und Verbrauchern bekannt (BSI-Lagebericht 2025). Jedes solche Leak kann Material für das Durchprobieren an anderer Stelle liefern, und es veraltet langsam: Ein Passwort, das seit Jahren unverändert im Einsatz ist, bleibt auch dann brauchbar, wenn der Datensatz selbst alt ist. Genau deshalb ist die Zahl der Leaks für einen Shop relevant, der selbst kein Datenleck hatte.

Auf der Seite der Betroffenen misst der Cybersicherheitsmonitor. Von den Befragten, die in den letzten zwölf Monaten von Cyberkriminalität betroffen waren, berichteten 2026 14 Prozent von einem Fremdzugriff auf einen Online-Account; davor lag der Wert bei 8 Prozent (2025), 15 Prozent (2024) und 20 Prozent (2023) (Cybersicherheitsmonitor 2026). Die Reihe schwankt, sie steigt nicht gleichmäßig an. Gut jede und jeder Vierte (27 Prozent) war überhaupt schon einmal von Cyberkriminalität betroffen, bei 40 Prozent dieser Gruppe lag mindestens ein Vorfall in den vergangenen zwölf Monaten (Cybersicherheitsmonitor 2026).

Auf der Unternehmensseite zählt der Wirtschaftsschutz-Bericht des Bitkom, der auf einer repräsentativen Befragung von 1.003 Unternehmen in Deutschland ab 10 Beschäftigten und mindestens 1 Million Euro Jahresumsatz beruht (Bitkom). In dieser Gruppe verursachten Angriffe auf Passwörter 2026 bei 18 Prozent der Unternehmen einen Schaden, Phishing bei 16 Prozent und Überlastungsangriffe bei 15 Prozent (Bitkom). Erpressungssoftware liegt mit 25 Prozent darüber, allerdings nach 34 Prozent im Vorjahr und 31 Prozent im Jahr 2024 (Bitkom). Passwortangriffe sind damit keine Randerscheinung – und von den genannten Schadensursachen diejenige, gegen die sich an der eigenen Anmeldemaske unmittelbar etwas ausrichten lässt.

Die polizeiliche Statistik liefert die dritte Perspektive. Für 2025 weist die Polizeiliche Kriminalstatistik zusammengefasst 333.922 Cybercrime-Fälle aus, ein Anstieg von 0,2 Prozent gegenüber dem Vorjahr (BKA). Die Belastung bleibt damit auf hohem Niveau nahezu unverändert. Angezeigte Angriffe mit Verschlüsselungstrojanern nahmen im selben Jahr auf 1.041 Fälle zu, 10 Prozent mehr als im Vorjahr (BKA). Eine eigene Fallgruppe für Kontoübernahmen im Handel führt die Statistik nicht. Wer die Zahl für den eigenen Shop sucht, findet sie ausschließlich im eigenen Protokoll – und nur dann, wenn dieses Protokoll fehlgeschlagene Anmeldungen überhaupt aufbewahrt.

Warum die Zählung je IP-Adresse nicht reicht

Die naheliegende Abwehr ist eine Obergrenze je IP-Adresse, und gegen ein einzelnes Skript greift sie auch. Gegen fertige Werkzeugkästen greift sie häufig nicht: Viele von ihnen verteilen ihre Anfragen über Proxy-Netze auf sehr viele verschiedene IP-Adressen, sodass das Anfragevolumen je Adresse niedrig bleibt. Das kann sowohl IP-Sperrlisten als auch eine Ratenbegrenzung je Adresse aushebeln, selbst bei Angriffen mit hohem Gesamtvolumen (OWASP). Verteilt sich derselbe Angriff auf ebenso viele Adressen, wie er Versuche unternimmt, bleibt je Adresse ein einziger Versuch übrig – und der ist von einer gewöhnlichen Anmeldung nicht zu unterscheiden.

Woher diese Adressen stammen können, lässt sich in der Größenordnung einordnen: Das BSI meldete im Berichtszeitraum täglich rund 40.000 infizierte Systeme an die deutschen Netzbetreiber (BSI-Lagebericht 2025). Welchen Anteil solche Systeme am Anmeldeverkehr eines Shops haben, beziffert keine der hier verwendeten Quellen; die Zahl beschreibt das Reservoir, nicht den Verkehr an Ihrer Anmeldemaske. Für die Abwehr folgt daraus eine nüchterne Konsequenz: Die Herkunft einer Anfrage ist ein schwaches Merkmal, das Verhalten über viele Konten hinweg ist ein starkes. Woran eine Welle im Protokoll erkennbar wird:

• Die Verteilung ist flach statt spitz: viele Konten, wenige Versuche je Konto.
• Die Fehlerquote der Anmeldung steigt, ohne dass sich Aussendungen, Kampagnen oder Tageszeit geändert haben.
• Anfragen treffen die Anmeldung direkt, ohne dass vorher Kategorie- oder Produktseiten geladen wurden.
• Der Anteil unbekannter Nutzernamen steigt: Es wird gegen Adressen angemeldet, die im Shop kein Konto haben.
• Erfolgreiche Anmeldungen häufen sich bei Konten, die lange nicht benutzt wurden.
• Nach einer erfolgreichen Anmeldung folgt keine Bestellung, sondern eine Änderung von Adresse, Zahlungsart oder Hinterlegtem.

Wird eine Adresse tatsächlich gesperrt, gehört zur Sperre von Anfang an ihr Ende. OWASP empfiehlt, Sperren einzelner IP-Adressen befristet zu setzen und einen Prozess vorzuhalten, der sie wieder aufhebt, sobald der Missbrauch nachlässt oder endet (OWASP). Der Grund ist betrieblich: Hinter einer Adresse steht oft ein ganzes Netz, ein Mobilfunkanbieter oder der Ausgang eines Firmennetzes. Eine unbefristete Sperre trifft dann Kunden, die nichts getan haben, und sie fällt selten auf, weil die Betroffenen sich nicht beschweren, sondern gehen. Wie sich automatisierter Verkehr von Kundenverkehr trennen lässt, ohne zur Vollsperre zu greifen, zeigt der Beitrag zu Bot-Traffic im Shop.

Die Abwehrkette in fünf Stufen

Keine einzelne Maßnahme hält eine Anmeldewelle auf. Wirksam wird eine Kette, in der jede Stufe einen anderen Teil des Angriffs verteuert: Die Ratenbegrenzung kostet Zeit, die mehrstufige Anmeldung kostet Anfragen, der Sperrlistenabgleich entwertet die erbeuteten Passwörter, der zweite Faktor entwertet das Passwort insgesamt, und der Reaktionsweg begrenzt den Schaden bei den Konten, die trotzdem gefallen sind. Die Stufen sind bewusst unabhängig voneinander: Fällt eine aus, greifen die übrigen weiter.

Die dritte Stufe wird regelmäßig unterschätzt, weil sie technisch banal aussieht. Eine mehrstufige Anmeldung – Nutzername und Passwort nacheinander, oder ein Token, das vor der Anmeldung geholt werden muss – macht den Angriff nicht unmöglich, aber sie verdoppelt die Zahl der Anfragen, die ein Angreifer je Konto senden muss (OWASP). Für die Gegenseite verdoppeln sich damit Kosten und Dauer, für den Kunden ändert sich der Ablauf kaum. Solche Maßnahmen wirken in der Summe: Jede einzelne verschiebt die Wirtschaftlichkeit des Angriffs ein Stück, und ab einem bestimmten Punkt wandert er zum nächsten Ziel.

Für die Ratenbegrenzung selbst gibt es eine belastbare Obergrenze. NIST begrenzt in SP 800-63B-4 die aufeinanderfolgenden Fehlversuche je Konto und Authentifikator auf höchstens 100 und verlangt danach die Abschaltung dieses Authentifikators (NIST). Das ist eine Obergrenze, kein Zielwert: Im Shop ist eine deutlich niedrigere Schwelle üblich, kombiniert mit einer wachsenden Verzögerung statt einer harten Sperre. Der Vorteil der Verzögerung ist, dass sie den Angriff verlangsamt, ohne ein Konto auszusperren, das gerade jemandem gehört, der sein Passwort nicht mehr weiß.

<?php
// Zählung je Konto UND je Netzbereich: eine Welle verteilt sich über viele
// Adressen, trifft aber dieselbe Anmeldemaske.
final class Anmeldeschutz
{
    private const FENSTER = 900;      // Beobachtungsfenster in Sekunden
    private const GRENZE_KONTO = 10;  // Fehlversuche je Konto im Fenster
    private const GRENZE_NETZ = 60;   // Fehlversuche je Netzbereich im Fenster

    public function __construct(private \Redis $speicher) {}

    public function darfVersuchen(string $konto, string $netz): bool
    {
        return $this->stand('konto:' . $konto) < self::GRENZE_KONTO
            && $this->stand('netz:' . $netz) < self::GRENZE_NETZ;
    }

    public function fehlversuch(string $konto, string $netz): void
    {
        foreach (['konto:' . $konto, 'netz:' . $netz] as $schluessel) {
            $neu = $this->speicher->incr('anmeldung:' . $schluessel);
            if ($neu === 1) {
                $this->speicher->expire('anmeldung:' . $schluessel, self::FENSTER);
            }
        }
    }

    public function erfolg(string $konto): void
    {
        // Nur der Kontozähler fällt. Der Netzzähler bleibt stehen, sonst
        // löscht jeder Treffer die Spur der Fehlversuche daneben.
        $this->speicher->del('anmeldung:konto:' . $konto);
    }

    private function stand(string $schluessel): int
    {
        return (int) $this->speicher->get('anmeldung:' . $schluessel);
    }
}

Zwei Dinge sind an dieser Konstruktion wichtiger als die konkreten Werte. Erstens läuft der Zähler je Konto und je Netzbereich getrennt, denn eine Welle erzeugt je Konto kaum Auffälligkeiten, je Netzbereich aber sehr wohl. Zweitens setzt ein erfolgreicher Anmeldevorgang nur den Kontozähler zurück. Würde er auch den Netzzähler löschen, könnte ein einziger Treffer die Spur der Fehlversuche daneben beseitigen – und genau dieses Muster, ein Treffer unter vielen Fehlversuchen, ist das Kennzeichen des Verfahrens. Der Speicher dafür sollte außerhalb des Anwendungsprozesses liegen, damit die Zähler im verteilten Betrieb über alle Webknoten hinweg dieselben sind.

Passwortregeln nach den aktuellen NIST-Richtlinien

Viele Shops arbeiten noch mit Regeln, die aus den Empfehlungen des vergangenen Jahrzehnts stammen. Die aktuelle Fassung der Digital Identity Guidelines dreht mehrere davon um. Dient das Passwort als einziger Faktor, verlangt NIST mindestens 15 Zeichen (NIST); als Höchstlänge sollen mindestens 64 Zeichen zugelassen werden (NIST). Beides zusammen bedeutet: Länge wird zugelassen statt beschnitten. Eine Obergrenze von 20 Zeichen, wie sie in älteren Shopsystemen vorkommt, schließt genau die Passphrasen aus, die sich Kunden merken können, ohne sie wiederzuverwenden.

• Beim Anlegen und Ändern eines Passworts gegen eine Sperrliste bekannter, häufig genutzter oder kompromittierter Passwörter prüfen (NIST).
• Keinen turnusmäßigen Passwortwechsel verlangen – das schließen die NIST-Richtlinien ausdrücklich aus (NIST).
• Keine Zusammensetzungsregeln erzwingen, etwa vorgeschriebene Mischungen aus Zeichenarten (NIST).
• Neue Passwörter gegen Leak-Datensätze prüfen; OWASP verweist dafür auf die Anforderung 2.1.7 des Application Security Verification Standard v4.0 (OWASP).
• Ein Zurücksetzen nach Verdacht auslösen, statt es dem Kunden zu überlassen – und dabei alle offenen Sitzungen des Kontos beenden.

Der Sperrlistenabgleich ist die Stufe, die Credential Stuffing an der Wurzel trifft: Ein Passwort, das auf der Sperrliste steht, wird beim Anlegen oder Ändern abgewiesen. In der Umsetzung gibt es zwei Wege. Entweder die Liste liegt im eigenen Betrieb – eine Sammlung von Prüfsummen, die beim Setzen eines Passworts abgefragt wird – oder die Prüfung läuft gegen einen Abgleichdienst, der nur ein Präfix der Prüfsumme sieht. Der erste Weg hält die Daten im Haus und ist bei begrenztem Listenumfang gut beherrschbar; der zweite verlagert Pflege und Umfang nach außen und bringt damit eine Abhängigkeit mit, die in der Verarbeitungsübersicht auftauchen muss.

Der zweite Faktor und was ihn im Shop bremst

Die zweite Stufe der Anmeldung wird 2026 häufiger genutzt als im Vorjahr. Die Zwei-Faktor-Anmeldung nutzen 2026 nach eigener Angabe 40 Prozent der Befragten nach 34 Prozent im Vorjahr, passwortloses Anmelden 21 Prozent nach 16 Prozent (Cybersicherheitsmonitor 2026). Der Begriff Passkeys war in der Verbraucherbefragung des BSI 38 Prozent der Befragten bekannt, genutzt hatten ihn 18 Prozent (BSI-Lagebericht 2025). Gleichzeitig nutzen 8 Prozent der Befragten überhaupt keine Schutzmaßnahme gegen Cyberangriffe (Cybersicherheitsmonitor 2026). Ein Shop kann sich also weder darauf verlassen, dass seine Kundschaft den zweiten Faktor kennt, noch darauf, dass sie ihn ablehnt.

In der Praxis scheitert der zweite Faktor selten an der Technik und häufig an der Platzierung. Wer ihn an jede Anmeldung hängt, verliert Bestellungen; wer ihn nur im Konto vergräbt, erreicht die Kunden nicht, die ihn brauchen. Eine Stufung nach Risiko ist erfahrungsgemäß tragfähig: gewöhnliche Anmeldung ohne zusätzliche Hürde, zweiter Faktor bei Anmeldung von einem unbekannten Gerät, bei Änderung von Zahlungsdaten, Lieferadresse oder Hinterlegtem und beim Zurücksetzen des Passworts. Wie die passwortlose Anmeldung technisch funktioniert, steht im Beitrag zu Passkeys im E-Commerce; wie sich die Registrierung dabei nicht in die Länge zieht, im Beitrag zur Gestaltung von Kundenkonten.

Wenn ein Konto übernommen wurde

Der Reaktionsweg ist ein Teil der Kette, der häufig fehlt, obwohl sich etwa jede und jeder dritte Betroffene an den Betreiber des Dienstes wendet. Von den in den letzten zwölf Monaten Betroffenen wandten sich 2026 35 Prozent an den Betreiber des Dienstes, 32 Prozent erstatteten Anzeige (Cybersicherheitsmonitor 2026). Betreiber und Polizei sind damit etwa gleich häufig Anlaufstelle. Für einen Shop heißt das: Der Weg muss besetzt sein, und zwar mit einer Person, die handeln darf, nicht nur mit einem Postfach. Ein Kunde, der einen Fremdzugriff meldet und drei Tage auf eine Standardantwort wartet, ist in der Regel doppelt verloren. Wie ein Rückmeldeweg aufgebaut wird, der besetzt ist und eine Frist einhält, zeigt der Beitrag zur Barrierefreiheitserklärung mit Feedback-Mechanismus.

1. Alle offenen Sitzungen des betroffenen Kontos beenden, nicht nur die aktuelle.
2. Passwort zurücksetzen und den zweiten Faktor neu einrichten, statt den alten weiterlaufen zu lassen.
3. Hinterlegte Daten prüfen: Lieferadressen, Zahlungsarten, Rufnummer, E-Mail-Adresse – genau die Felder, die ein Angreifer zuerst ändert.
4. Bestellungen der letzten Tage sichten und offene Sendungen stoppen, solange sie das Lager nicht verlassen haben.
5. Dem Kunden schreiben, was passiert ist und was er selbst tun sollte – vor allem dann, wenn dasselbe Passwort anderswo im Einsatz ist.
6. Den Vorfall im Protokoll festhalten: Zeitpunkt, Herkunft, betroffene Konten. Ohne diese Notiz lässt sich später nicht unterscheiden, ob es ein Einzelfall oder eine Welle war.

Die Auswertung zeigt das Muster deutlicher als jede Vermutung: viele Adressen, kaum Wiederholungen je Adresse, ganz überwiegend ein einziger Fehlversuch je Nutzername. Der Nutzername steht nicht im Zugriffsprotokoll des Webservers, weil er im Anfragekörper übertragen wird; die letzte Abfrage stützt sich darum auf ein eigenes Anmeldeprotokoll des Shops, das je Fehlversuch Zeitpunkt, IP-Adresse und eine Prüfsumme des Nutzernamens in dieser Reihenfolge schreibt. Eine Ratenbegrenzung je IP-Adresse hätte hier fast nichts zu sperren gehabt. Damit solche Auswertungen möglich sind, müssen fehlgeschlagene Anmeldungen überhaupt protokolliert werden – mit Zweckbindung, Aufbewahrungsfrist und der Entscheidung, ob die Adresse gekürzt gespeichert wird. Was dabei zu beachten ist, gehört in die Verarbeitungsübersicht und in den Datenschutz; wer im Backend auf diese Protokolle schauen darf, regelt die Rechtevergabe im Shop-Backend.

Wer welche Pflicht hat

Rechtlich ist die Lage klarer, als sie oft dargestellt wird – vor allem, was den Adressatenkreis angeht. Besonders wichtige und wichtige Einrichtungen müssen nach § 30 Absatz 2 Nummer 10 BSIG Lösungen zur Multi-Faktor-Authentifizierung oder zur kontinuierlichen Authentifizierung einsetzen (BSIG). Das BSI-Gesetz in der Fassung der NIS2-Umsetzung ist am 6. Dezember 2025 in Kraft getreten (BSIG). Die Pflicht trifft damit nicht jeden Shopbetreiber, sondern die im Gesetz bestimmten Einrichtungen. Wer dazugehört und was daraus folgt, behandelt der Beitrag zur NIS2-Richtlinie für Online-Händler.

Für dieselben Einrichtungen gilt eine gestufte Meldekette. Ein erheblicher Sicherheitsvorfall ist unverzüglich, spätestens jedoch innerhalb von 24 Stunden nach Kenntniserlangung als frühe Erstmeldung an die gemeinsame Meldestelle zu melden, mit der Angabe, ob ein Verdacht auf rechtswidriges oder böswilliges Handeln oder auf grenzüberschreitende Auswirkungen besteht (BSIG). Praktisch heißt das: Die Entscheidung, ob ein Vorfall erheblich ist, muss vor dem Vorfall vorbereitet sein. Eine Einordnung, die erst im Ernstfall diskutiert wird, verbraucht genau die Stunden, die die Frist vorgibt.

Hinzu kommt eine Verordnung, deren Zeitplan gern verkürzt wiedergegeben wird. Die Verordnung (EU) 2024/2847 über horizontale Cybersicherheitsanforderungen für Produkte mit digitalen Elementen gilt ab dem 11. Dezember 2027; Artikel 14 mit den Meldepflichten der Hersteller gilt jedoch bereits seit dem 11. September 2026, Kapitel IV seit dem 11. Juni 2026 (Verordnung (EU) 2024/2847). Die Meldepflichten sind also geltendes Recht und keine Ankündigung. Sie treffen Hersteller von Produkten mit digitalen Elementen – relevant für Shopbetreiber vor allem dann, wenn eigene Software oder vernetzte Produkte vertrieben werden. Den Zuschnitt beschreibt der Beitrag zum Cyber Resilience Act.

Wo Angreifer nach den Zahlen einsteigen

Für die Frage, wie viel Aufmerksamkeit die Anmeldemaske verdient, lohnt der Blick auf die Eindringvektoren. ENISA hat für den Threat Landscape 2025 insgesamt 4.875 Vorfälle gesammelt und ausgewertet (ENISA). Innerhalb der Fälle, bei denen sich der Eindringvektor bestimmen ließ, entfielen rund 60 Prozent auf Phishing einschließlich Vishing, Malspam und Malvertising, 21,3 Prozent auf das Ausnutzen von Schwachstellen, 9,9 Prozent auf Botnetze, 8 Prozent auf schadhafte Anwendungen und 0,8 Prozent auf unbefugten Zugriff durch Innentäter (ENISA). Die Anteile summieren sich innerhalb dieser Teilmenge auf das Ganze: Sie beschreiben die Verteilung unter den Fällen mit bestimmtem Eindringvektor und nicht den Anteil an allen ausgewerteten Vorfällen, die insgesamt von Überlastungsangriffen bestimmt werden.

Die zweite Zahl dieses Kapitels erklärt den Nachschub für das Durchprobieren: Von den erfassten Eindringvorfällen führten 68,6 Prozent zu Datenabflüssen, die anschließend in Untergrundforen zum Verkauf angeboten wurden (ENISA). Auch dieser Wert bezieht sich auf die Eindringvorfälle, nicht auf jeden Sicherheitsvorfall. Zusammengenommen ergibt sich ein Kreislauf: Ein Einbruch anderswo erzeugt Zugangsdaten, die gehandelt werden, und diese Zugangsdaten treffen Wochen später auf Anmeldemasken, die mit dem ursprünglichen Vorfall nichts zu tun haben. Der eigene Shop ist in diesem Kreislauf der Prüfstand, nicht die Quelle.

Anmeldewellen vor der Hochsaison abfangen

Die Reihenfolge der Arbeiten ergibt sich aus dem Aufwand: Zuerst kommt das Zählen, dann das Begrenzen, dann die Passwortregeln, dann der zweite Faktor. Wir beginnen deshalb mit dem Protokoll und prüfen, ob fehlgeschlagene Anmeldungen überhaupt auswertbar abgelegt werden. Danach richten wir die Zähler je Konto und je Netzbereich ein, ziehen die Passwortregeln auf den heutigen Stand der NIST-Richtlinien und legen fest, an welchen Stellen ein zweiter Faktor verlangt wird. Für die Lastseite derselben Vorbereitung – Kapazität, Notfallplan, Ausweichweg – gibt es den Beitrag zu Lasttest und Notfallplan.

• Bestandsaufnahme der Anmeldestrecke: Welche Wege führen zur Anmeldung, welche davon sind ratenbegrenzt, welche nicht?
• Zähler je Konto, je Nutzername und je Netzbereich einrichten, gemeinsam über alle Webknoten.
• Passwortregeln angleichen: Mindestlänge, zugelassene Höchstlänge, Sperrlistenabgleich, kein turnusmäßiger Wechsel.
• Zweiten Faktor risikobasiert einhängen, beginnend bei Änderungen an Zahlungs- und Adressdaten.
• Reaktionsweg festlegen: wer meldet, wer entscheidet, wer schreibt dem Kunden – mit Vertretung.
• Nach vier Wochen nachmessen: Fehlversuche je Konto, Anteil unbekannter Nutzernamen, erfolgreiche Anmeldungen nach langer Kontoruhe.

Wir richten diese Kette im laufenden Betrieb ein und ändern die Anmeldung für die Kundschaft nur dort, wo eine Stufe es verlangt: Zähler und Protokoll kommen zuerst, die Schwellen werden anhand der gemessenen Verteilung gesetzt und nicht anhand eines Richtwerts aus einem fremden Shop. Wenn Sie wissen möchten, wie Ihre Anmeldestrecke im Bestand dasteht, ist der Shop-Check der kurze Weg; für Betrieb, Protokollierung und Zähler über mehrere Knoten hinweg der Weg über Hosting und Betrieb. In beiden Fällen gilt: Erst messen, dann begrenzen – eine Schwelle, die aus einer Vermutung stammt, sperrt in der Regel die falschen Leute aus.