Brute-Force-Schutz: Rate-Limiting, Lockout, CAPTCHA

1. Warum Login-Formulare ein bevorzugtes Angriffsziel sind

Login-Endpunkte gehören zu den am stärksten automatisiert angegriffenen Flächen eines Magento-Shops, weil sie öffentlich erreichbar sind und ein einziger Treffer direkten Zugriff auf ein Konto, eine Bestellhistorie oder im schlimmsten Fall das Admin-Panel liefert. Tools wie Hydra, Medusa oder selbstgeschriebene Skripte gegen die REST-API testen automatisiert tausende Kombinationen pro Minute, oft aus rotierenden Botnetzen heraus, um klassische IP-Sperren zu umgehen.

Der Unterschied zwischen einem naiven und einem robusten Brute-Force-Schutz entscheidet direkt darüber, ob ein Angriff nach wenigen Sekunden auffällt oder wochenlang unbemerkt bleibt. Ein kompromittiertes Kundenkonto im Magento-Checkout ermöglicht Betrugsbestellungen über gespeicherte Zahlungsdaten, ein kompromittiertes Admin-Konto ermöglicht vollständige Übernahme des Shops. Die folgenden Abschnitte behandeln die einzelnen Bausteine eines abgestuften Schutzkonzepts, von Lockout über Rate-Limiting bis zur Multi-Faktor-Authentifizierung.

2. Account-Lockout und das Denial-of-Service-Risiko

Die naheliegendste Reaktion auf wiederholte Fehlversuche ist die Sperrung des betroffenen Kontos nach einer festen Anzahl fehlgeschlagener Logins. Dieses Muster hat jedoch eine wenig beachtete Kehrseite: Wenn die Sperrung ausschließlich am Benutzernamen oder an der E-Mail-Adresse hängt, kann ein Angreifer gezielt fremde Konten lahmlegen, indem er absichtlich mehrfach ein falsches Passwort für eine bekannte E-Mail-Adresse eingibt. Das Ergebnis ist ein Denial-of-Service gegen legitime Nutzer, ganz ohne dass der Angreifer jemals ein Passwort erraten muss.

In einem Online-Shop wird dieses Risiko besonders greifbar: Ein Konkurrent oder böswilliger Nutzer könnte gezielt Konten von Kunden kurz vor einem Kaufabschluss sperren, oder alle bekannten Admin-Benutzernamen eines Shops dauerhaft blockieren. Die Gegenmaßnahme ist, Lockout nie isoliert, sondern immer im Kontext von IP-Adresse, Gerät und Zeitfenster zu betrachten, und harte Sperren durch progressive Verzögerung zu ersetzen oder zumindest zu ergänzen, bevor ein Konto vollständig gesperrt wird.

3. Progressive Verzögerung: exponentielles Backoff pro Versuch

Statt ein Konto nach dem dritten Fehlversuch hart zu sperren, verzögert progressive Verzögerung jeden weiteren Versuch um eine wachsende Zeitspanne. Ein typisches Muster ist exponentielles Backoff: Die Wartezeit verdoppelt sich mit jedem Fehlversuch, beginnend bei einer Sekunde, begrenzt durch eine sinnvolle Obergrenze von wenigen Minuten. Für einen legitimen Nutzer, der sich zweimal vertippt, ist die Verzögerung kaum spürbar. Für einen automatisierten Angreifer, der tausende Kombinationen pro Minute testen will, wird der Angriff wirtschaftlich unattraktiv.

Wichtig ist, die Verzögerung serverseitig durchzusetzen und niemals im Client zu berechnen, da ein Angreifer clientseitige Wartezeiten trivial umgeht. Die Zählung der Fehlversuche sollte in einem schnellen Speicher wie Redis erfolgen, mit einer Ablaufzeit (TTL), die den Zähler nach einer definierten Ruhephase automatisch zurücksetzt. So bleibt der Mechanismus selbstheilend, ohne manuelles Zurücksetzen durch den Support.

<?php

declare(strict_types=1);

namespace Mironsoft\LoginProtection\Model;

/**
 * Calculates and enforces progressive delay for failed login attempts.
 */
final class ProgressiveDelayGuard
{
    private const BASE_DELAY_SECONDS = 1;
    private const MAX_DELAY_SECONDS = 300;
    private const RESET_AFTER_SECONDS = 900;

    public function __construct(
        private readonly \Mironsoft\LoginProtection\Model\AttemptStoreInterface $attemptStore
    ) {
    }

    /**
     * Returns the number of seconds the caller must wait before retrying.
     *
     * @param string $identifier Account identifier or IP address
     * @return int Seconds to wait, 0 if the next attempt is allowed immediately
     */
    public function getRequiredWaitSeconds(string $identifier): int
    {
        $failures = $this->attemptStore->getFailureCount($identifier, self::RESET_AFTER_SECONDS);
        if ($failures === 0) {
            return 0;
        }

        // Exponential backoff: delay doubles per failure, capped at MAX_DELAY_SECONDS
        $delay = self::BASE_DELAY_SECONDS * (2 ** min($failures, 12));

        return (int) min($delay, self::MAX_DELAY_SECONDS);
    }

    /**
     * Records a failed login attempt for the given identifier.
     *
     * @param string $identifier Account identifier or IP address
     * @return void
     */
    public function recordFailure(string $identifier): void
    {
        $this->attemptStore->increment($identifier, self::RESET_AFTER_SECONDS);
    }

    /**
     * Clears the failure counter after a successful login.
     *
     * @param string $identifier Account identifier or IP address
     * @return void
     */
    public function recordSuccess(string $identifier): void
    {
        $this->attemptStore->reset($identifier);
    }
}

4. IP-basiertes und konten-basiertes Rate-Limiting kombinieren

Rate-Limiting ausschließlich auf Basis der IP-Adresse übersieht zwei häufige Situationen: Mehrere legitime Nutzer teilen sich hinter einem Firmen-NAT oder VPN dieselbe öffentliche IP, wodurch ein einzelner falscher Login mehrere Kollegen aussperrt. Umgekehrt verteilt ein Angreifer mit einem Botnetz seine Versuche über hunderte IP-Adressen, sodass jede einzelne IP unterhalb der Erkennungsschwelle bleibt, während das Zielkonto insgesamt tausende Versuche erhält. Reines IP-Limiting löst also weder das Verteilungsproblem des Angreifers noch das Kollateralschaden-Problem der Nutzer.

Die belastbare Lösung kombiniert beide Signale mit unterschiedlichen, bewusst gewählten Schwellenwerten: ein grobmaschiges Limit pro IP-Adresse als erste Verteidigungslinie gegen einzelne aggressive Quellen, und ein feinmaschigeres, kontenbasiertes Limit mit progressiver Verzögerung als zweite Ebene gegen verteilte Angriffe auf ein einzelnes Ziel. Auf Infrastrukturebene lässt sich das grobe IP-Limit bereits vor der Anwendung im Webserver durchsetzen, was Ressourcen spart, weil offensichtlich exzessive Anfragen gar nicht erst den PHP-Prozess erreichen.

# nginx.conf: coarse IP-based rate limiting as first line of defense
# in front of the Magento login and REST auth endpoints

limit_req_zone $binary_remote_addr zone=login_zone:10m rate=5r/m;
limit_req_status 429;

server {
    listen 443 ssl http2;
    server_name shop.example.com;

    location = /customer/account/loginPost {
        limit_req zone=login_zone burst=3 nodelay;
        limit_req_log_level warn;
        try_files $uri /index.php$is_args$args;
    }

    location = /rest/V1/integration/customer/token {
        limit_req zone=login_zone burst=3 nodelay;
        try_files $uri /index.php$is_args$args;
    }

    location = /admin {
        # Admin login gets a stricter zone with lower burst tolerance
        limit_req zone=login_zone burst=1 nodelay;
        try_files $uri /index.php$is_args$args;
    }
}

5. CAPTCHA-Platzierung: risikobasiert statt bei jedem Login

Ein CAPTCHA bei jedem einzelnen Login-Versuch anzuzeigen wirkt auf den ersten Blick sicher, verschlechtert aber messbar die Conversion, weil jeder zusätzliche Klick und jede zusätzliche Ladezeit Nutzer zum Abbruch bewegt, besonders auf mobilen Geräten. Die wirksamere Strategie ist risikobasiertes CAPTCHA: Es erscheint nicht standardmäßig, sondern erst, wenn bestimmte Signale auf ein erhöhtes Risiko hindeuten, etwa eine bestimmte Anzahl von Fehlversuchen für ein Konto oder eine IP-Adresse, ein ungewöhnlich neues Gerät oder eine auffällige Anfragegeschwindigkeit.

Unsichtbare Varianten wie reCAPTCHA v3 oder hCaptcha berechnen im Hintergrund einen Risiko-Score, ohne den Nutzer aktiv zu stören, und lösen erst bei niedrigem Score eine sichtbare Challenge aus. Für Magento-Shops bedeutet das: CAPTCHA als letzte Eskalationsstufe nach Rate-Limiting und progressiver Verzögerung einsetzen, nicht als erste Hürde vor jedem einzelnen Login. Diese Reihenfolge hält die Reibung für die überwiegende Mehrheit der legitimen Nutzer bei null und aktiviert den Schutz nur für den kleinen Anteil verdächtiger Anfragen.

// Trigger a CAPTCHA challenge only after suspicious activity,
// never on the first login attempt of a session.

const FAILURE_THRESHOLD_FOR_CAPTCHA = 3;

/**
 * Decides whether a CAPTCHA challenge must be rendered for the next
 * login attempt, based on recent failure count and risk signals.
 * @param {number} recentFailures Failed attempts for this account/IP pair
 * @param {number} riskScore Risk score from an invisible check (0 = risky, 1 = trusted)
 * @returns {boolean} True if a visible CAPTCHA challenge is required
 */
function requiresCaptchaChallenge(recentFailures, riskScore) {
  if (recentFailures >= FAILURE_THRESHOLD_FOR_CAPTCHA) {
    return true;
  }
  // Invisible risk assessment (e.g. reCAPTCHA v3) below trust threshold
  return riskScore < 0.5;
}

async function handleLoginSubmit(formData, recentFailures) {
  const riskScore = await fetchInvisibleRiskScore(formData);

  if (requiresCaptchaChallenge(recentFailures, riskScore)) {
    return renderVisibleChallenge();
  }

  return submitLogin(formData);
}

6. Magentos eingebauten Login-Schutz konfigurieren

Magento bringt mit dem Modul Magento_Security bereits einen konfigurierbaren Grundschutz mit, der über den Admin-Bereich unter Stores > Configuration > Advanced > Admin > Security gesteuert wird. Dort lassen sich die maximale Anzahl fehlgeschlagener Login-Versuche vor einer Sperre, die Sperrdauer in Minuten sowie die Passwort-Lebensdauer und die Passwortkomplexität festlegen. Für den Customer-Login existiert eine vergleichbare, separate Konfiguration unter Stores > Configuration > Customers > Customer Configuration > Login Options, die unabhängig vom Admin-Bereich eigene Schwellenwerte erlaubt.

Modulentwickler können diese Werte über system.xml erweitern oder eigene Felder ergänzen, während config.xml sinnvolle Standardwerte für Neuinstallationen liefert. Die eigentliche Sperrlogik liegt in Magento\Security\Model\AdminSessionsManager und im Magento\Security\Model\SecurityChecker, die bei jedem Login-Versuch geprüft werden. Wichtig für Betreiber mehrerer Websites: Die Admin-Lockout-Werte gelten global für den Adminhouse-Bereich, während Customer-Lockout-Einstellungen pro Website konfigurierbar sind, was bei Multi-Site-Setups explizit geprüft werden sollte.

<!-- app/code/Mironsoft/LoginProtection/etc/adminhtml/system.xml -->
<?xml version="1.0"?>
<config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xsi:noNamespaceSchemaLocation="urn:magento:module:Magento_Config:etc/system_file.xsd">
    <system>
        <section id="admin" translate="label" type="text" sortOrder="10"
                 showInDefault="1" showInWebsite="0" showInStore="0">
            <group id="security" translate="label" type="text" sortOrder="1"
                   showInDefault="1" showInWebsite="0" showInStore="0">
                <!-- Native Magento_Security fields, referenced for context -->
                <field id="lockout_failures" translate="label" type="text"
                       sortOrder="30" showInDefault="1">
                    <label>Maximum Login Failures to Lockout Account</label>
                </field>
                <field id="lockout_threshold" translate="label" type="text"
                       sortOrder="40" showInDefault="1">
                    <label>Lockout Time (minutes)</label>
                </field>
            </group>
        </section>
    </system>
</config>

<!-- app/code/Mironsoft/LoginProtection/etc/config.xml -->
<?xml version="1.0"?>
<config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xsi:noNamespaceSchemaLocation="urn:magento:module:Magento_Store:etc/config.xsd">
    <default>
        <admin>
            <security>
                <!-- Lock the admin account after 5 failed attempts -->
                <lockout_failures>5</lockout_failures>
                <!-- Lockout duration in minutes -->
                <lockout_threshold>30</lockout_threshold>
            </security>
        </admin>
        <customer>
            <login_options>
                <max_login_failures>6</max_login_failures>
                <lockout_time>15</lockout_time>
            </login_options>
        </customer>
    </default>
</config>

7. Credential Stuffing vs. Brute Force: der Unterschied zählt

Klassischer Brute Force testet viele Passwörter gegen ein oder wenige bekannte Konten, oft mit Wortlisten oder systematischer Zeichenkombination. Credential Stuffing funktioniert umgekehrt: Der Angreifer nutzt E-Mail-Passwort-Paare aus früheren Datenlecks anderer Dienste und testet jede Kombination genau einmal, aber gegen sehr viele verschiedene Konten. Weil pro Konto meist nur ein einziger Versuch stattfindet, bleibt konten-basiertes Rate-Limiting nahezu wirkungslos, da der Fehlversuchszähler für jedes Konto einzeln bei null oder eins bleibt.

Erkennbar wird Credential Stuffing über andere Signale: eine ungewöhnlich hohe Anzahl unterschiedlicher Benutzernamen, die von derselben IP-Adresse oder demselben Gerätefingerabdruck in kurzer Zeit ausprobiert werden. Zusätzlich hilft der Abgleich neuer Passwörter gegen bekannte Leak-Datenbanken wie die Pwned-Passwords-API von Have I Been Pwned bei der Registrierung und Passwortänderung, um kompromittierte Zugangsdaten von vornherein abzulehnen, bevor sie überhaupt für einen Angriff nutzbar werden.

<?php

declare(strict_types=1);

namespace Mironsoft\LoginProtection\Model;

/**
 * Detects credential stuffing by tracking distinct usernames attempted
 * from the same IP address within a short time window using Redis.
 */
final class CredentialStuffingDetector
{
    private const WINDOW_SECONDS = 300;
    private const DISTINCT_USERNAME_THRESHOLD = 10;

    public function __construct(
        private readonly \Redis $redis
    ) {
    }

    /**
     * Records a login attempt and returns whether the IP looks like
     * a credential stuffing source rather than a single-account attack.
     *
     * @param string $ipAddress Client IP address
     * @param string $username Attempted username or email
     * @return bool True if this IP has tried too many distinct accounts
     */
    public function trackAndEvaluate(string $ipAddress, string $username): bool
    {
        $key = 'stuffing:' . hash('sha256', $ipAddress);

        $this->redis->sAdd($key, hash('sha256', strtolower($username)));
        $this->redis->expire($key, self::WINDOW_SECONDS);

        return $this->redis->sCard($key) >= self::DISTINCT_USERNAME_THRESHOLD;
    }
}

8. Monitoring und Alerting bei wiederholten Fehlversuchen

Rate-Limiting und Lockout verhindern erfolgreiche Angriffe, aber ohne Monitoring bleibt ein laufender Angriff für das Team unsichtbar, bis der Schaden bereits entstanden ist. Jeder fehlgeschlagene Login sollte strukturiert geloggt werden, mit Zeitstempel, IP-Adresse, betroffenem Benutzernamen und Ergebnis der Risikobewertung, idealerweise zentral in einem SIEM-System oder einer Log-Pipeline wie ELK oder Grafana Loki statt verstreut in lokalen Magento-Logdateien.

Magentos admin_user-Tabelle speichert bereits failures_num und lock_expires, die sich per Cronjob auswerten und bei Überschreiten eines Schwellenwerts an Slack, PagerDuty oder E-Mail eskalieren lassen. Für den Customer-Bereich lohnt sich ein eigener Alert auf ungewöhnliche Muster: ein plötzlicher Anstieg fehlgeschlagener Logins über viele Konten hinweg deutet stärker auf Credential Stuffing als auf gezielten Brute Force gegen ein einzelnes Konto und sollte unterschiedlich behandelt werden, etwa durch temporäres Verschärfen der globalen Rate-Limits statt einzelner Kontosperren.

9. Multi-Faktor-Authentifizierung als ergänzende Schutzebene

Seit Magento 2.4 ist Magento_TwoFactorAuth für den Admin-Bereich standardmäßig aktiv und unterstützt TOTP-Apps wie Google Authenticator sowie U2F/WebAuthn-Sicherheitsschlüssel. Multi-Faktor-Authentifizierung (MFA) verhindert nicht, dass ein Angreifer Login-Versuche durchführt, sie verhindert den erfolgreichen Abschluss eines Angriffs, selbst wenn das korrekte Passwort erraten oder aus einem Datenleck stammt. Deshalb ersetzt MFA kein Rate-Limiting: Ohne Ratenbegrenzung kann ein Angreifer weiterhin unbegrenzt Passwörter testen und den zweiten Faktor als eigenständiges Ziel angreifen, etwa durch SIM-Swapping bei SMS-basierten Codes.

Für Magento-Shops ist die Kombination entscheidend: MFA für alle Admin-Konten verpflichtend, WebAuthn bevorzugt gegenüber SMS wegen der Phishing-Resistenz, und für Kunden optionale MFA als Zusatzangebot, besonders bei gespeicherten Zahlungsdaten. Rate-Limiting, progressive Verzögerung und CAPTCHA bleiben auch mit aktivierter MFA notwendig, weil sie die Angriffsfläche vor dem zweiten Faktor bereits reduzieren und die Serverlast durch automatisierte Angriffe begrenzen.

10. Zusammenfassung

Ein tragfähiger Brute-Force-Schutz besteht nie aus einer einzelnen Maßnahme, sondern aus mehreren aufeinander abgestimmten Ebenen. Account-Lockout allein birgt das Risiko, dass Angreifer legitime Nutzer gezielt aussperren, deshalb sollte progressive Verzögerung mit IP-Kontext die erste Verteidigungslinie bilden. Rate-Limiting muss IP- und kontenbasierte Signale kombinieren, weil weder verteilte Botnetz-Angriffe noch gezielte Angriffe auf ein einzelnes Konto durch eine einzelne Dimension zuverlässig erkannt werden. CAPTCHA gehört an das Ende der Eskalationskette, nicht an den Anfang jedes Logins, um Conversion-Verluste zu vermeiden.

Magentos Magento_Security-Modul liefert brauchbare Grundeinstellungen für Admin- und Customer-Login, die aber je nach Shop-Größe und Risikoprofil angepasst werden sollten. Credential Stuffing erfordert andere Erkennungssignale als klassischer Brute Force, insbesondere die Anzahl unterschiedlicher Benutzernamen pro Quelle. Monitoring und Alerting machen laufende Angriffe sichtbar, bevor Schaden entsteht, und Multi-Faktor-Authentifizierung ergänzt, ohne Rate-Limiting zu ersetzen. Zusammen bilden diese Bausteine ein Defense-in-Depth-Konzept, das sowohl automatisierte Massenangriffe als auch gezielte Attacken gegen einzelne hochwertige Konten abdeckt.

11. FAQ: Brute-Force-Schutz