Credential Stuffing: Prevention, Detection, and Response for Application Teams
Retool's new app builder is where AI-generated code ships safely
Building apps with AI is easy. Getting them to production safely is another story.
Credential stuffing is the most common form of account takeover at scale. The supply of breach credential data has grown to billions of records, freely available on dark web markets and criminal forums, and attackers have industrialized the process of testing those credentials against target applications using distributed bot networks. Unlike brute force attacks, there are no obvious per-account lockout signals because each credential pair is tested once with a legitimate username and a real password from a prior breach.
The defense requires a different mental model than brute force protection. You are not looking for repeated attempts against single accounts — you are looking for population-level anomalies: thousands of accounts being tested rapidly across a distributed IP space, with a success rate that is higher than your normal rate for new IPs but lower than would be expected from legitimate users who have forgotten their password.
Defense layers: what actually stops stuffing
No single control stops credential stuffing — attackers adapt to individual controls quickly, especially pure IP-based or lockout-based defenses. Effective defense requires overlapping layers that collectively make automated credential testing economically unviable. The three primary layers are bot detection at the login endpoint, rate limiting with exponential backoff at the IP and ASN level, and breach password checking via the HIBP k-anonymity API at account creation and password change. Each layer addresses a different attack vector: bot detection stops automated tooling signatures, rate limiting raises the operational cost of distributed attacks, and HIBP integration eliminates the most vulnerable accounts from the population before an attack ever begins.
Layer 1: Bot detection at the login endpoint
Deploy a bot management solution (Cloudflare Bot Management, DataDome, Kasada, or Arkose Labs) specifically on the login, password reset, and account creation endpoints. These solutions analyze dozens of signals (JavaScript fingerprinting, behavioral biometrics, device attributes, IP reputation, TLS fingerprint) to score each request as bot or human. Credential stuffing tools have consistent signatures: headless browser fingerprints, no natural mouse movement or typing cadence, identical user agent strings across thousands of requests. Bot management blocks stuffing attempts before they reach your authentication logic, eliminating both the attack load and the baseline pollution that makes anomaly detection harder.
Layer 2: Rate limiting with exponential backoff
Apply layered rate limits: per-IP limits (5 failed attempts per IP per 15 minutes), per-account limits (10 failed attempts per account per hour), and global login failure rate limits (alert if the aggregate failure rate exceeds 2x the 7-day rolling average). Use exponential backoff — each failed attempt increases the delay before the next attempt can be made from that IP. For IPs in known datacenter or proxy ASNs (check ASN reputation), require CAPTCHA or additional verification immediately rather than waiting for failed attempt count. Log all rate limit events as security events and alert on spikes.
Layer 3: Check new passwords against breach data
Integrate the HIBP k-anonymity API into your password change and account creation flows. When a user sets a new password: compute SHA-1 of the password, send the first 5 hex characters to api.pwnedpasswords.com/range/{prefix}, receive the list of matching hash suffixes, check if the full hash suffix appears in the response. If the password is in breach data, reject it and prompt for a different password. This eliminates the most vulnerable accounts from your user base: accounts where the user's password is already in the breach credential list that attackers will use in their next stuffing campaign.
Detection and monitoring
Even with prevention layers in place, active credential stuffing attacks will generate signals in your login logs that your SIEM or application monitoring layer should surface in near-real-time. The detection rules that catch stuffing are fundamentally different from per-account brute force rules: they operate on aggregate login behavior across all accounts rather than tracking failed attempts for individual users. This section covers the specific alert thresholds and SIEM rules that flag an active stuffing campaign, and the post-attack account review process that identifies which accounts authenticated successfully during the attack window and may be compromised.
Login anomaly detection rules
Build these SIEM or application-layer detection rules: (1) Alert: failed login rate > 3x 7-day rolling average for any 15-minute window. (2) Alert: any single IP exceeds 10 unique-username login attempts in 10 minutes. (3) Alert: login success rate for new IPs drops below 30% (normal user success rate for new IPs is 80-90%; stuffing success rate is typically 1-10%). (4) Alert: user agent string representing automated tool appears in more than 50 login attempts in any hour. (5) Alert: geographic impossibility — same account logged in successfully from two countries in the same hour (impossible travel, may indicate stuffing success). These rules generate signals that a human or SOAR automation can investigate.
Post-stuffing account review process
After an attack is detected and contained: identify all accounts that authenticated successfully during the attack window from flagged IPs or with flagged user agents. Review each for post-login activity: profile changes, email changes, password changes (lock-out pattern), financial transactions, or data exports. Any account with suspicious post-login activity is likely compromised. Force password reset for all accounts that logged in during the attack window from anomalous IPs, even if no suspicious post-login activity was observed — the cost of a false positive (legitimate user resets password) is lower than the cost of a missed compromise.
Briefings like this, every morning before 9am.
Threat intel, active CVEs, and campaign alerts, distilled for practitioners. 50,000+ subscribers. No noise.
The bottom line
Credential stuffing defense requires accepting that per-account lockout policies are insufficient and pivoting to population-level detection and prevention. The effective stack: bot management at the login endpoint, rate limiting with exponential backoff, breach password checking via HIBP, MFA enrollment for high-value accounts, and anomaly detection rules that alert on aggregate login behavior rather than per-account failed attempts. When an attack is detected, the response workflow is: block attacker IPs at the WAF or CDN, force-review all successful logins during the attack window, notify and reset accounts that show post-compromise activity, and enroll all affected accounts in enhanced MFA.
Frequently asked questions
How is credential stuffing different from brute force attacks?
Brute force attacks try many passwords for a single account, making per-account lockout policies effective. Credential stuffing tries a single real credential pair (from a prior breach) against each account, using valid usernames and passwords — it does not guess. Account lockout policies are ineffective against stuffing because the attacker typically makes one login attempt per account (with the known password) before moving on. Stuffing detection requires different signals: cross-account velocity (many accounts being tested rapidly), IP reputation (known proxy/datacenter IPs), user agent diversity (same user agent string used for thousands of login attempts), and login failure rate spikes that exceed baseline by orders of magnitude.
How do I detect a credential stuffing attack in my login logs?
Stuffing attacks leave statistical fingerprints. Alert on: login failure rate exceeding 3x baseline over any 15-minute window, concentrated failure spike followed by a wave of successful logins (indicates the attacker switched to valid pairs after finding the right format), large number of unique IP addresses logging in failed attempts within a short window (distributed IPs suggest proxy network use), unusual user agent strings (old browser versions, headless browser signatures like 'python-requests', 'curl', or no user agent), and user accounts logging in from a new country with no prior access history. Log all login attempts (successes and failures) including IP, user agent, and timestamp for at least 90 days to enable investigation.
What is the HIBP API and should I use it to check user passwords?
Have I Been Pwned (HIBP) is a service maintained by Troy Hunt that indexes over 10 billion credential pairs from known breaches. The API uses k-anonymity to allow password checking without transmitting the plaintext password: hash the password with SHA-1, send the first 5 characters to the API, receive back all hash suffixes matching that prefix, and check locally whether the full hash is in the list. If found, the password is in breach data. NIST SP 800-63B recommends checking new passwords against known breach lists during enrollment and password change. Implement HIBP integration to block passwords that appear in breach databases, reducing the population of vulnerable accounts without storing breach data yourself.
Does CAPTCHA stop credential stuffing?
Traditional image-based CAPTCHAs are largely ineffective against modern credential stuffing. Commercial CAPTCHA-solving services (2captcha, Anti-Captcha) charge $0.50-$2.00 per 1,000 solves, making CAPTCHA a minor cost adder rather than a blocker for large-scale operations. Google reCAPTCHA v3 (invisible, score-based) is more effective because it analyzes behavioral signals without requiring user interaction, making it harder to bypass than challenge-response CAPTCHAs. Modern bot detection services (Cloudflare Bot Management, DataDome, Kasada, Arkose Labs) use a combination of device fingerprinting, behavioral analysis, and challenge mechanisms that are significantly harder to bypass than CAPTCHA alone.
What should we do when a credential stuffing attack is detected in progress?
Immediate actions during an active attack: (1) Apply rate limiting at the IP and ASN level for IPs exceeding your normal login velocity threshold (be conservative to avoid false positives). (2) Require CAPTCHA or additional verification for any login from a new or suspicious IP. (3) Enable IP reputation blocking for known proxy and datacenter IP ranges via your WAF or CDN. (4) Alert on and queue for review any accounts that successfully logged in during the attack window — these may be compromised. (5) Temporarily increase the security score threshold for risk-based authentication if you use it. (6) Notify your security team and pull attack metrics (total attempts, success rate, source IP distribution) every 30 minutes during the active phase.
How do I handle accounts confirmed compromised by credential stuffing?
For accounts that authenticated successfully during an attack window: identify all accounts that successfully logged in from IPs flagged as part of the attack. Force-logout and invalidate all sessions for each identified account. Require password reset on next login. If financial data or sensitive transactions occurred during the compromised session: notify the user and review the session activity for unauthorized changes or transactions. Enroll affected accounts in enhanced monitoring (flag subsequent logins for review for 30 days). If the breach is widespread (more than 1% of your user base compromised): issue proactive breach notifications under applicable law, offer credit monitoring for high-value breaches, and consider proactively resetting all accounts that share passwords with the confirmed breach list.
How do I implement multi-factor authentication in a way that actually stops credential stuffing?
Not all MFA implementations stop credential stuffing equally. TOTP (Google Authenticator, Authy) stops stuffing because the attacker needs the current one-time code in addition to the password — this changes every 30 seconds and cannot be reused. SMS MFA is somewhat weaker (SIM swap attacks can bypass it) but still substantially reduces stuffing success. Push notification MFA (Duo, Microsoft Authenticator) stops stuffing but can be bypassed by MFA fatigue attacks. Passkeys (FIDO2) are the strongest option: the credential is device-bound and phishing-resistant, making stuffing against passkey-enrolled accounts essentially impossible. For accounts not yet enrolled in MFA: implement risk-based authentication that requires step-up MFA for logins from new devices, new locations, or during detected attack windows.
Sources & references
Free resources
Critical CVE Reference Card 2025–2026
25 actively exploited vulnerabilities with CVSS scores, exploit status, and patch availability. Print it, pin it, share it with your SOC team.
Ransomware Incident Response Playbook
Step-by-step 24-hour IR checklist covering detection, containment, eradication, and recovery. Built for SOC teams, IR leads, and CISOs.
Get threat intel before your inbox does.
50,000+ security professionals read Decryption Digest for early warnings on zero-days, ransomware, and nation-state campaigns. Free, daily, no spam.
Unsubscribe anytime. We never sell your data.
Founder & Cybersecurity Evangelist, Decryption Digest
Cybersecurity professional with expertise in threat intelligence, vulnerability research, and enterprise security. Covers zero-days, ransomware, and nation-state operations for 50,000+ security professionals every morning.
Win a $2,495 Black Hat pass.
Full-access to Black Hat USA 2026 in Las Vegas. Subscribe free to enter.