Account lockout bypass

Why This Matters

Credential brute-force and stuffing attacks represent a persistent threat against web authentication systems. The 2019 Disney+ launch saw accounts compromised within hours through credential stuffing from breach databases, and the 2020 Spotify stuffing attack affected approximately 300 000 accounts. OWASP lists broken authentication (A07:2021) as a top-ten risk with account lockout absence as a defining characteristic. Account lockout mechanisms are the primary server-side defence against online brute-force, but their implementation is commonly bypassed through IP rotation, header injection, and timing manipulation — techniques that testers must understand and enumerate thoroughly.

Core Concept

Account lockout is a server-side control that temporarily or permanently disables authentication attempts for an account after a defined number of consecutive failures, preventing automated password guessing. The mechanism's effectiveness depends on three parameters: the lockout threshold (number of failures before lockout), the lockout duration (how long the account remains locked), and the lockout scope (whether it is per-account, per-IP, or both).

The most common bypass exploits the server's reliance on the client IP address for rate-limiting. Many implementations use the X-Forwarded-For HTTP header — originally designed for reverse proxies to communicate the originating client IP — to identify the requesting IP. If the application trusts this header from untrusted clients, an attacker can spoof the source IP for rate-limiting purposes by setting X-Forwarded-For: 10.0.0.1 (or any value) in each request. By cycling through different values — either fake IPs or real rotating proxies — the attacker effectively resets the failure counter before it reaches the lockout threshold.

IP rotation bypass uses pools of real IP addresses (residential proxies, cloud exit nodes, Tor) to distribute the attack so that no single IP exceeds the lockout threshold. Combined with slow-spray timing, this evades both per-IP lockout and rate-limit-based detection.

Username enumeration via lockout timing is a side-channel: if locking a valid account causes a noticeably different response time (the server queries the database, updates a lockout record, and possibly sends an email) compared to failing against a nonexistent account, valid usernames leak without any successful authentication.

Credential stuffing pairs breach-database username:password pairs (RockYou2021, various combo lists) with an authenticated target application, relying on password reuse rather than brute-force. It is more efficient than brute-force and bypasses complexity-based lockout thresholds because each pair is tried only once.

Technical Deep-Dive

Testing X-Forwarded-For lockout bypass with Burp Intruder:

POST /login HTTP/1.1
Host: target.example.com
Content-Type: application/x-www-form-urlencoded
X-Forwarded-For: §10.0.0.§§1§

username=admin&password=§password_from_list§

Configure two payload sets in Pitchfork mode: Set 1 cycles through IP suffixes (1–254), Set 2 cycles through the password list. Each request presents a different IP to the lockout counter.

Other headers that may be honoured by misconfigured applications:

X-Real-IP: 192.168.1.1
X-Originating-IP: 192.168.1.1
X-Remote-IP: 192.168.1.1
X-Client-IP: 192.168.1.1
True-Client-IP: 192.168.1.1

Hydra credential brute-force with IP rotation via proxy list:

hydra -L users.txt -P /usr/share/wordlists/rockyou.txt 
      target.example.com http-post-form 
      "/login:username=^USER^&password=^PASS^:Invalid credentials" 
      -t 4 
      -w 5 
      -o hydra_results.txt
# For IP rotation, route through ProxyChains with a rotating proxy pool:
proxychains hydra ...

Distributed slow brute-force timing calculation:

# Lockout threshold: 5 attempts per account per hour
# Attack: 1 attempt per account per 70 minutes (safely below threshold)
# Username list: 10 000 accounts
# Passwords tested per day: (24 * 60) / 70 * 1 = ~20 passwords/day per account
# With 10 000 accounts in parallel: covers top-20 passwords across all accounts daily
# → Password spray is more effective than single-account brute-force

Security Assessment Methodology

1. Determine the lockout threshold — Submit progressively more wrong passwords for a test account while counting. Identify at which attempt the lockout triggers. Record the error message and HTTP status code at lockout.
2. Test X-Forwarded-For bypass — After triggering lockout, wait for reset (or create a fresh test account). Add X-Forwarded-For: 1.2.3.4 to a login request. Increment the header value with each request to determine whether the lockout counter resets. Use Burp Intruder for efficiency.
3. Test other IP headers — Try X-Real-IP, X-Originating-IP, True-Client-IP, and CF-Connecting-IP. Different reverse proxy configurations honour different header names.
4. Measure lockout timing side-channel — Compare response times for: (a) wrong password for a valid account, (b) wrong password at the lockout threshold, (c) any input for a nonexistent account. Statistically significant timing differences indicate username enumeration is possible.
5. Test credential stuffing resilience — Use a small, known breach list (construct a synthetic one for testing) to determine whether the application applies any additional controls (CAPTCHA, device fingerprinting, anomaly detection) beyond lockout.
6. Verify lockout notification — A secure implementation should notify the account owner of lockout events. Test whether the application sends email/SMS alerts and whether those alerts themselves leak information.

Defensive Countermeasure — Implement lockout that is account-scoped rather than IP-scoped, never trust client-supplied IP headers for security decisions, supplement lockout with CAPTCHA or proof-of-work challenges that activate after the second failed attempt, and monitor for distributed low-rate attempts that individually stay below the per-IP threshold.

Common Assessment Errors

• Testing only the primary IP header — Many testers try only X-Forwarded-For. Applications may trust X-Real-IP, True-Client-IP, or custom headers. Test all common variants.
• Not testing lockout recovery — Confirming that lockout triggers is not sufficient. Confirm that the account unlocks only after the correct duration, and that a correct password during the lockout period still fails.
• Conflating brute-force and credential stuffing — These are different techniques with different countermeasure implications. Brute-force tests one account with many passwords; credential stuffing tests many accounts with one (breach-derived) password. Report them separately.
• Using aggressive timing that triggers WAF — High-speed Hydra attacks often trigger Web Application Firewall blocks before the lockout mechanism is even reached. Throttle requests to isolate the application-layer lockout behaviour from WAF responses.
• Ignoring username enumeration in lockout messages — "Your account has been locked" confirms the username is valid; "Invalid username or password" does not. Different lockout messages for valid vs invalid usernames are a reportable enumeration finding.
• Missing the "username spray" variant — Password spraying (one password, many accounts) avoids single-account lockout entirely. Always test whether the application has any cross-account rate limiting.

NICE Framework Alignment

Further Reading

• OWASP Testing Guide v4.2, OTG-AUTHN-003: Testing for Weak Lock Out Mechanism — OWASP Foundation
• Credential Stuffing Prevention Cheat Sheet — OWASP Foundation
• Hacking Web Authentication — Dafydd Stuttard (Portswigger research)