Credential Stuffing Defence — Rate Limits, MFA, Checks

Your login page works exactly as designed: it accepts correct passwords and rejects wrong ones. That correctness is the vulnerability. Attackers arrive holding millions of username-password pairs spilled from breaches elsewhere, and your login can't tell a legitimate user from a thief holding that user's reused password. Every attempt looks like an ordinary login, because cryptographically it is one.

Password reuse makes this devastating. People reuse passwords across dozens of sites, so a breach of a forum in 2019 becomes the key to bank, email, and shopping accounts in 2026. Automated tooling tries thousands of pairs per minute, distributed across botnets that dodge naive IP bans, and even a 0.1% success rate on a million-pair list yields a thousand compromised accounts.

Defending logins therefore means changing what 'correct' requires. Rate limiting and bot detection raise the cost of guessing, breach-corpus screening stops users choosing already-stolen passwords, and MFA — especially phishing-resistant WebAuthn — makes a stolen password insufficient by itself. This guide builds that layered defence: what stuffing looks like in your logs, which brakes actually work, and how to respond when the wave arrives.

Why Stolen Passwords Keep Working

Password reuse is the fuel and breach compilations are the match. The average person reuses a handful of passwords across dozens of accounts, and every breach — forums, games, shops, newsletters — adds millions of working pairs to attacker dictionaries. Compilations with billions of entries circulate permanently; a password spilled in 2019 is still being tried against new sites today, because nobody told the password it expired.

Stuffing tooling industrializes the trying. Credential lists feed automated runners that distribute attempts across residential proxies and botnets, solve basic CAPTCHAs, mimic real browsers, and rotate user agents — each IP staying under naive rate limits while the aggregate hammers your endpoint. Success rates look small (fractions of a percent) until you multiply by list sizes in the millions. Your login page's politeness — clear error messages, fast responses, no account enumeration care — helps legitimate users and attackers equally.

Accept the uncomfortable premise: some of your users' passwords are already public, and your login cannot distinguish those users from the thieves holding their credentials. Every defence in this guide follows from that premise. You slow the trying so campaigns cost more than they earn, you reject known-stolen secrets at the door, and you demand proof beyond the password so a correct guess still isn't enough.

Rate Limiting vs Account Lockout: Picking the Right Brake

Not all brakes are safe to press. Hard account lockouts (N failures freeze the account) convert password guessing into account denial: attackers spray bad passwords across your user base and your own security control locks out thousands of legitimate users by morning. Unless paired with instant self-serve unlock (email link, verified device), lockouts are a weapon you hand to the attacker — most teams should avoid them as the primary control.

Progressive delays scale pain with suspicion instead: the first failures cost nothing, then each subsequent failure adds waiting time per account. Humans fat-fingering twice never notice; automation burning thousands of attempts bleeds hours. Layer per-IP buckets underneath for volumetric floods, device fingerprinting to separate known devices from new ones, and step-up challenges (CAPTCHA, then MFA) when velocity or anomaly scores cross thresholds. Each layer asks more of strangers while asking nothing extra of recognized users.

The snippet below shows the per-account progressive delay pattern — the single highest-value control for teams with only IP limiting today. Store attempt counters server-side with expiries, compute delay from consecutive failures, and enforce it before checking the password so timing reveals nothing. Pair it with alerting on aggregate failure ratios, because the delay slows attackers but it's your monitoring that ends campaigns.

import time
from functools import wraps

_attempts: dict[str, list[float]] = {}  # use Redis in production
WINDOW, BASE_DELAY = 900, 1.0  # 15-min window, 1s base

def login_delay(username: str) -> float:
    now = time.time()
    recent = [t for t in _attempts.get(username, []) if now - t < WINDOW]
    _attempts[username] = recent
    return min(BASE_DELAY * (2 ** len(recent)), 32.0)  # cap at 32s

def record_attempt(username: str, success: bool) -> None:
    if success:
        _attempts.pop(username, None)  # reset on good login
    else:
        _attempts.setdefault(username, []).append(time.time())

def throttle(username: str) -> None:
    delay = login_delay(username)
    if delay > BASE_DELAY:
        time.sleep(delay)  # slow automation, invisible to humans

MFA and WebAuthn That Survive Stolen Passwords

MFA is the control that makes stuffing mathematically pointless: the breach gave attackers passwords, not second factors. Authenticator apps (TOTP) and hardware keys stop virtually all replayed-password logins for enrolled accounts — the incident above would have been 4,100 failed attempts instead of 4,100 takeovers if those accounts had any second factor at all. The technology works; enrollment is the entire battle.

Not all second factors are equal. SMS codes are better than nothing but vulnerable to SIM swapping and interception; authenticator apps resist those but not real-time phishing (a fake login page relays the code in seconds). WebAuthn and passkeys bind the credential to your site's origin — the key simply won't answer a lookalike domain — defeating phishing and stuffing simultaneously. Prefer platform passkeys for consumers (zero hardware to ship) and hardware keys for admins and finance roles.

Drive enrollment like a product launch, not a suggestion. Require MFA for privileged actions from day one, prompt standard users at natural moments (first login, security settings visits), and celebrate progress with a visible enrollment KPI. For accounts that remain unenrolled, compensate with tighter anomaly thresholds and faster step-up challenges — and keep recovery flows strict, because attackers who can't stuff the front door will try the 'I lost my phone' window next.

Breach Monitoring with the K-Anonymity Pattern

If a user's new password already appears in breach compilations, attackers own it on day one — rejecting it at creation is pure prevention. The k-anonymity API pattern (pioneered by the haveibeenpwned password service) makes this check privacy-safe: hash the candidate password with SHA-1 locally, transmit only the first 5 hex characters, receive all matching suffixes, and compare locally. The service never sees the full hash, let alone the password, yet you learn exactly whether it's been seen in breaches and how often.

Apply the check at every password-set moment: registration, password change, and admin resets — plus periodic re-screening of existing hashes against fresh breach data, since today's safe choice becomes tomorrow's compilation entry. On a match, reject with actionable guidance: explain the password appeared in breaches, suggest a password manager, and offer generated alternatives. Never shame the user; the reuse habit is universal and the fix should feel helpful, not punitive.

The snippet below implements the client side of the pattern — note what's absent: no password leaves the machine, only a 5-character prefix. Cache responses briefly to survive API outages without blocking registration, and fail open carefully (log, allow, and re-check later) rather than failing closed on users during an outage. This single check would have forced resets for the 22,000 additional reused passwords found after the incident above — before attackers tried them.

import hashlib
import urllib.request

def password_is_breached(candidate: str, timeout: int = 5) -> bool:
    digest = hashlib.sha1(candidate.encode()).hexdigest().upper()
    prefix, suffix = digest[:5], digest[5:]  # only prefix leaves us
    with urllib.request.urlopen(
        f"https://api.pwnedpasswords.com/range/{prefix}",
        timeout=timeout) as resp:
        suffixes = {line.split(":")[0] for line in
                    resp.read().decode().splitlines()}
    return suffix in suffixes  # full hash never transmitted

def validate_new_password(candidate: str) -> str | None:
    if len(candidate) < 12:
        return "Use at least 12 characters."
    if password_is_breached(candidate):
        return "That password appeared in breaches — pick another."
    return None  # acceptable

Bot Signals and Step-up Challenges

Distributed stuffing looks human per-request and inhuman in aggregate — your detection must think in aggregates. Track failure ratios per hour (a jump from 5% to 30%+ is the classic wave signature), unique IPs per targeted account, impossible-travel logins, and datacenter or hosting-ASN origins for supposedly consumer logins. Device fingerprints and behavioral signals (typing cadence, mouse movement, TLS fingerprints) add per-request suspicion scores that feed step-up decisions.

Step-up challenges convert suspicion into cost without punishing real users. Low scores pass silently; medium scores get a CAPTCHA or email verification; high scores demand MFA or block pending review. The key property is asymmetry: each challenge costs automation real money (CAPTCHA solving, phone numbers, time) while costing recognized users nothing. Tune thresholds from logged outcomes — every false challenge teaches you about a legitimate pattern (travel, new phone, password manager autofill).

Keep a human in the loop for tuning, not for triage. Automated playbooks should freeze redemptions, force challenges, and page on-call when wave signatures fire; analysts then review aggregate dashboards, not individual logins. The bash probe below gives responders a one-command wave check: failure ratio plus IP spread over the last hour, the two numbers that distinguish stuffing from a bad deploy or a Monday morning.

# One-command stuffing wave check over the last hour of auth logs
# Log format assumed: ISO-time user ip result(success|failure)
awk '$1 > "$(date -u -d "1 hour ago" +%FT%T)"' /var/log/auth.log \
  | awk '{total++; if ($4=="failure") fail++; ips[$3]=1}
         END {printf "attempts=%d failures=%d ratio=%.1f%% unique_ips=%d\n",
               total, fail, (total?100*fail/total:0), length(ips)}'
# Wave signature: ratio >30% AND unique_ips in the thousands.

Alerting and Playbooks for Stuffing Waves

Waves arrive at 2 AM on holidays — your response quality equals your preparation, not your heroics. Define wave signatures as alerts, not observations: failure-ratio thresholds, IP-spread thresholds, impossible-travel volumes, and fraud-action spikes each page with runbook links attached. The runbook's first page is containment toggles (redemption freeze, global step-up, ASN blocks), because decision fatigue at 3 AM is how 9-hour incidents happen.

Rehearse the playbook quarterly with tabletop exercises: a simulated wave, a communications drill (who tells users, what the status page says, when regulators get notified), and a fraud-account recovery flow that returning victims can complete without calling support. Measure recovery experience like a product metric — victims who reset easily stay customers; victims who fight your process for a week leave and tell everyone.

After each wave, convert findings into permanent controls: new ASN blocks, tightened thresholds, expanded breach-screening, enrollment pushes for victim cohorts. The incident above ended with 22,000 preventive resets that should have been 22,000 rejections at password-set time. Every wave is a free penetration test of your login defences — grade it, fix the gaps it found, and make the next identical campaign fail silently at your front door.

groups:
  - name: login-abuse
    rules:
      - alert: CredentialStuffingWave
        expr: |
          rate(auth_logins_failed_total[5m])
            / rate(auth_logins_total[5m]) > 0.30
        for: 10m
        labels:
          severity: page
        annotations:
          summary: 'Login failure ratio above 30% for 10m (possible wave)'