Login
Free Trial

How to Prevent Credential Stuffing Attacks on Your Website

captcha.eu

Credential stuffing attacks use real passwords stolen from prior breaches, not guesswork. That makes them faster, harder to detect, and more damaging than brute force. This guide covers the six defences that stop them, what to do if an attack is already running and which endpoints to protect first.

Estimated reading time: 16 minutes

Try CAPTCHA.eu free – no credit card
View all integrations

At a Glance

What makes it different

Attackers use real, working passwords from prior breaches, not random guesses. Login attempts look legitimate on the surface

Why it succeeds

Around 85% of users reuse passwords across multiple services. Even a 0.1% success rate on one billion credentials yields one million compromised accounts

Strongest single defence

MFA. It stops account takeover even when the attacker has the correct password. Microsoft data shows it blocks over 99% of automated account compromise attacks

Why CAPTCHA fits here

Proof-of-work CAPTCHA stops bots before they reach your login logic and raises the cost of every attempt regardless of whether the credentials are valid

What this guide covers

How credential stuffing works

Every major data breach produces a side effect: a list of working usernames and passwords ends up on the dark web. Attackers buy these lists cheaply, sometimes for just a few dollars per million records, and then test them automatically against other services. The logic is simple: if someone used the same email and password for a breached retail site and their banking account, the attacker now has access to both.

A typical credential stuffing campaign runs like this:

  1. Acquire credentials. Attackers buy or download breach databases from dark web marketplaces. Lists containing billions of username-password pairs are widely available and cheap.
  2. Prepare the list. Tools enrich the raw data, deduplicate it, and format it for automated testing across multiple target sites.
  3. Launch distributed login attempts. Bots submit login requests across thousands of IP addresses simultaneously, using real browser signatures to blend in with normal traffic. Each IP sends only a handful of requests, staying under rate limiting thresholds.
  4. Collect successes silently. When a login succeeds, the bot records it. The attacker then either sells the working credentials, takes over the account, drains stored value, or uses it as a foothold for further attacks.

The key detail is that the attacker never needs to guess. They are replaying passwords that already worked somewhere else. That changes everything about how the attack looks and how you detect it.

Credential stuffing vs. brute force: what is the difference?

Both attacks target login forms, and both use automation. Beyond that, they are very different problems that require different defences.

The simplest way to understand the difference

Think of brute force as a locksmith trying every possible key combination on your lock. It takes time, it makes noise, and it is obvious when it is happening. Credential stuffing is someone who found your key in a lost and found box and is quietly trying it on your door. The key looks real because it is. The only question is whether you changed the lock after the original breach.

ASPECT
CREDENTIAL STUFFING
BRUTE FORCE
Password source
Real passwords stolen from prior breaches
Generated guesses: random combinations, dictionaries
Success rate
Low per attempt (~0.1%), but huge at scale
Very low; depends heavily on password strength
Speed
Very fast; distributed across thousands of IPs
Slower; triggers lockouts and rate limits quickly
Detection difficulty
Hard: requests look like normal user logins
Easier: many failed attempts on one account stand out
Password policy helps?
No: the attacker already has a working password
Yes: longer, complex passwords slow the attack
Primary defence
MFA, CAPTCHA, breached-password screening
Account lockout, rate limiting, CAPTCHA, MFA

The most important row is the second-to-last one. Strong password policies protect well against brute force because they make guessing harder. Against credential stuffing, they provide almost no protection, because the attacker is not guessing. They have your password already. This is why the two attacks need different thinking, even though they share some common defences.

For a deeper look at brute force specifically, see our guide on how to prevent brute force attacks.

Why credential stuffing is so hard to detect

This is the core challenge. When a brute force attack runs, it leaves obvious traces: dozens or hundreds of failed login attempts against the same account from the same IP address. Your logs light up. Monitoring tools fire alerts.

Credential stuffing leaves almost none of those traces. The attacker distributes requests across thousands of different IP addresses. Each IP sends just one or two requests. The credentials are correct, so many attempts succeed immediately. There are no repeated failures on the same account. The traffic looks exactly like normal users logging in from different locations.

The result is that many credential stuffing attacks run undetected for months. In the 23andMe case, attackers spent five months inside the platform before the company discovered what had happened. They found out only because stolen data appeared for sale on a hacker forum, not because internal monitoring detected anything.

The hidden cost of successful attacks

According to IBM’s Cost of a Data Breach Report 2025, breaches cost an average of $4.44 million globally and take 241 days to identify and contain on average. The financial damage includes fraud remediation, customer notification, regulatory fines, and reputational harm, on top of the direct losses from compromised accounts.

A real-world example: 23andMe

In October 2023, the genetic testing company 23andMe disclosed a credential stuffing attack that ultimately exposed the personal data of approximately 6.9 million users. The scale of the breach makes it one of the clearest case studies in how credential stuffing can escalate far beyond the initial compromise.

Case study: 23andMe (2023)

Attackers obtained credential lists from prior, unrelated data breaches and used them to access 23andMe accounts whose owners had reused passwords. Approximately 14,000 accounts were directly compromised through this method. However, 23andMe’s “DNA Relatives” feature, which lets users share genetic ancestry data with connected profiles, amplified the breach dramatically. By accessing 14,000 accounts, the attacker could scrape connected data from an additional 5.5 million profiles, and Family Tree data from 1.4 million more. None of those additional users had their accounts directly compromised. Their data was exposed simply because a connected user had reused a password.

The five-month detection gap (the attack ran from April to September 2023, discovered only when stolen data appeared on BreachForums) highlights the monitoring failure that allows credential stuffing to run silently. 23andMe subsequently mandated password resets and introduced two-step verification. The company faced a $30 million class action settlement and filed for Chapter 11 bankruptcy in March 2025. Regulators in the UK and Canada found that adequate monitoring controls were absent.

The 23andMe breach illustrates three lessons that apply to almost any website with user accounts. First, your users’ passwords from other sites put your platform at risk, even if you have never been breached. Second, platform features that connect accounts can multiply the impact of a single compromised login. Third, if you do not monitor for the right signals, you will not know an attack is running until someone else tells you.

Six defences that work

  • Multi-factor authentication

    MFA is the single most effective defence against credential stuffing. The reason is structural: even if an attacker has the correct username and password, MFA requires a second verification step (a time-based code, a push notification, or a hardware key) that the attacker does not have. Microsoft’s analysis of account compromise incidents found that MFA would have stopped over 99% of them. That figure applies directly to credential stuffing, because the entire attack model depends on a stolen password being sufficient to log in. For website operators, the priority is straightforward: make MFA mandatory for administrator and high-privilege accounts, and offer it to all users. Where you cannot enforce MFA for every user, deploy it for high-risk actions: account details changes, payment flows, and password resets. FIDO2 passkeys and authenticator apps are now widely supported and reduce the friction that historically made MFA unpopular with users.

MFA alone does not stop the attack traffic

MFA prevents account takeover, but it does not stop bots from submitting login attempts. Thousands of MFA-blocked attempts still hit your server, consume resources, and generate noise in your logs. That is why MFA works best combined with the layers below.

  • Proof-of-work CAPTCHA on login and authentication flows

    CAPTCHA acts at a different point in the attack chain than MFA. Rather than blocking account takeover after a successful login, CAPTCHA raises the cost of every login attempt before it reaches your authentication logic. This matters enormously for credential stuffing, where attackers rely on submitting millions of requests cheaply and automatically. The type of CAPTCHA matters here. AI-powered solving tools and human-solving services.” Traditional visual CAPTCHA (image grids, “I am not a robot” checkboxes) is increasingly bypassed by AI-powered solving tools and human-solving services. Against a resourced attacker running a large credential stuffing campaign, a visual CAPTCHA provides less protection than it appears to. Proof-of-work CAPTCHA is structurally different. Instead of presenting a visual puzzle, it requires the browser to complete a small cryptographic computation before the login request can proceed. For a real user, this happens invisibly in the background. For a bot submitting thousands of login attempts per minute, every single attempt now requires computational work, raising the cost regardless of the attacker’s image-solving capability. The OWASP Credential Stuffing Prevention Cheat Sheet identifies CAPTCHA as one of the key controls for slowing credential stuffing attacks, specifically noting its role in raising the cost and time of automated login attempts.

CAPTCHA.eu stops bots before they reach your login logic

Invisible proof-of-work verification on every login attempt. No image puzzles. No cookies. All data processed in Austria under EU law. WACA Silver certified by TÜV Austria against WCAG 2.2 AA.

Start free trial
See how login abuse works

  • Breached-password screening

    This defence is underused and highly effective. When a user creates an account or changes their password, your system checks the new password against a database of credentials known to have been exposed in prior data breaches. If it finds a match, it rejects the password and asks the user to choose a different one. The New York State Attorney General’s credential stuffing investigation identified breached-password screening as one of the most impactful controls available to operators, specifically because it prevents users from creating accounts with passwords that are already circulating in attacker databases. The service Have I Been Pwned offers a free API for exactly this purpose, allowing you to check passwords against billions of known breached credentials without transmitting the actual password. This control does not stop an attack already in progress, but it reduces your exposure significantly over time by eliminating your most vulnerable accounts before attackers reach them.

  • Rate limiting and anomaly detection

    Standard IP-based rate limiting (blocking an IP after a set number of failed login attempts) is less effective against credential stuffing than against brute force, because each IP in a stuffing campaign typically makes only one or two requests. However, rate limiting still has an important role when applied thoughtfully. The more effective approach combines per-account thresholds with global anomaly detection. Per-account thresholds flag when the same account receives login attempts from many different IPs in a short window. Global anomaly detection flags when your login endpoint suddenly receives significantly more traffic than baseline, even if no individual account or IP is behaving suspiciously. Together, these patterns catch distributed campaigns that evade simple IP rate limiting. Additional signals worth monitoring: login attempts that come from known proxy or hosting provider IP ranges, logins from unusual geographic locations for existing accounts, and successful logins immediately followed by account detail changes. The OWASP Credential Stuffing Cheat Sheet recommends combining multiple signals rather than relying on any single threshold.

  • Consistent error messages on login failure

    This is a small detail that matters more than it appears. If your login page returns different messages for “wrong password” versus “account does not exist,” attackers can use those differences to validate which usernames in their list are real accounts. A simple change: always return the same generic message regardless of whether the username exists or the password is wrong. “Email address or password is incorrect” reveals nothing. “We could not find an account with that email address” is a gift to an attacker building a validated username list. The same logic applies to password reset flows. Returning different responses for valid versus invalid email addresses allows attackers to enumerate your user base with no login credentials at all.

  • User notification and monitoring

    Even with all of the above in place, some attacks will succeed. Fast detection limits the damage. The most effective monitoring signals for credential stuffing are different from those for brute force. Look for: a general increase in login volume without a corresponding increase in successful logins, successful logins from unfamiliar geographic locations or devices for established accounts, account detail changes (email address, password, shipping address) shortly after login, and elevated password reset request rates. Notify users immediately when their account is logged into from a new device or location. Give users visibility into their recent login history. If they can see that someone in another country logged in at 3am, they can take action before the attacker does lasting damage. This also shifts some of the detection burden from your security team to your users, which scales better than centralised monitoring alone.

Where to start: which endpoints to protect first

Apply these defences to your highest-risk flows first. Login forms are the primary target, because a successful credential stuffing login gives the attacker full account access immediately. After login, prioritise password reset flows, where different responses for valid versus invalid email addresses let attackers enumerate real accounts without needing any credentials. Then API authentication endpoints, which often lack the protections applied to web login forms. Finally, registration forms, where successful stuffing can create fake or cloned accounts. Protect in that order and you cover the vast majority of credential stuffing attack surface.

If an attack is already running: immediate steps

Detecting a credential stuffing attack in progress requires different signals than you might expect. Because individual requests look normal, the clearest signs are volume-level patterns: a sudden spike in login traffic, an unusual ratio of successful to failed logins, or new accounts being created with patterns that suggest automation (sequential usernames, identical browser signatures, bulk registrations in a short window).

If you identify an active attack, this sequence limits the damage:

  • Enable or tighten CAPTCHA immediately.

    Even deploying proof-of-work CAPTCHA mid-attack raises the cost for bots still submitting attempts and can slow or stop the campaign within minutes.

  • Apply temporary geo-blocking or proxy blocking on the login endpoint.

    Credential stuffing traffic frequently routes through hosting provider ranges and open proxies. Cloudflare and similar services publish IP lists for these. Blocking them is imperfect but buys time.

  • Force MFA or re-authentication on accounts showing anomalous activity.

    Any account that received a successful login from an unusual location or device should be challenged before the session continues.

  • Reset passwords for accounts showing suspicious successful logins.

    Notify affected users with clear instructions. Be specific: explain that their credentials may have been exposed in a prior breach elsewhere, and that they should not use the same password on other services.

  • Check for downstream activity in compromised accounts.

    Account detail changes, payment method additions, stored-value redemptions, and data exports are the actions an attacker takes after getting in. Review these in the window surrounding the attack.

  • Preserve your logs for the full attack window.

    Under GDPR and NIS2, you may have notification obligations if personal data was accessed. Raw logs are the foundation of any incident response or regulatory filing.

Add CAPTCHA.eu to your login flow in minutes

WordPress, TYPO3, Keycloak, Magento, and custom stacks. Austria-hosted, cookieless, no puzzles for real users. 100 free requests to start.

Start free trial
See all integrations

The EU dimension: why credential stuffing is a GDPR issue

For European website operators, a successful credential stuffing attack is not just a security incident. Under the GDPR, unauthorised access to personal data in user accounts constitutes a personal data breach and triggers a 72-hour notification obligation to your supervisory authority, as well as potential notification to affected users. The 23andMe case resulted in regulatory investigations by the UK Information Commissioner’s Office and the Office of the Privacy Commissioner of Canada, partly because the detection failure prevented timely breach notification.

This has a direct implication for how you think about credential stuffing defences. Deploying CAPTCHA and MFA is not only a security decision. It is also part of your GDPR Article 32 obligation to implement “appropriate technical measures” to protect personal data. Failing to do so, and subsequently suffering a breach, puts you in a difficult position during regulatory review.

The choice of CAPTCHA also has compliance implications. Traditional CAPTCHA services typically set tracking cookies on login pages, which triggers ePrivacy consent requirements and adds complexity to your consent management setup. CAPTCHA.eu operates without cookies by architecture, removing that compliance question entirely for operators who want bot protection without consent overhead on authentication flows.

Frequently Asked Questions

What is credential stuffing in simple terms?

Credential stuffing is when attackers take usernames and passwords stolen from one website and automatically try them on other websites. It works because many people reuse the same password across multiple services. The attacker does not guess. They use real credentials that already worked somewhere else.

How is credential stuffing different from a brute force attack?

Brute force attacks guess passwords through trial and error, trying combinations until one works. Credential stuffing uses known, working passwords from prior breaches. Brute force is easy to detect because it generates many failed login attempts. Credential stuffing is much harder to spot because the credentials are correct and the traffic looks like legitimate users logging in.

Does CAPTCHA stop credential stuffing?

Yes, but the type matters. Traditional image-based CAPTCHA is increasingly bypassed by AI-powered solving tools. Proof-of-work CAPTCHA is more effective because it requires a cryptographic computation for every login attempt, raising the cost of running a large-scale stuffing campaign regardless of the attacker’s image-recognition capability. CAPTCHA works best as one layer among several, combined with MFA and anomaly detection.

What is the most effective defence against credential stuffing?

MFA is the single strongest control because it stops account takeover even when the attacker has the correct password. Beyond MFA, the most impactful combination is: proof-of-work CAPTCHA on login endpoints, breached-password screening at registration and password change, and anomaly monitoring for unusual login patterns. No single layer is sufficient on its own.

How do I know if my website is under a credential stuffing attack?

Unlike brute force, credential stuffing does not generate obvious failed login spikes on single accounts. The clearest signals are: a general increase in login volume without a matching increase in page activity, successful logins from unusual locations or devices for established accounts, account detail changes shortly after login, and elevated password reset request rates. Modern CAPTCHA dashboards provide verification volume data that can surface unusual traffic patterns early.

Is credential stuffing a GDPR issue for European websites?

Yes. If a credential stuffing attack results in unauthorised access to user account data, that is a personal data breach under the GDPR. It triggers a 72-hour notification obligation to your supervisory authority and potentially to affected users. Deploying appropriate technical controls, including CAPTCHA and MFA, is part of your GDPR Article 32 obligation to protect personal data with suitable technical measures.

Does a strong password policy prevent credential stuffing?

No. Password policy protects against brute force by making guessing harder. Against credential stuffing, it provides almost no protection. The attacker already has a working password. What does help is breached-password screening (preventing users from setting passwords that have already been exposed in prior breaches) and MFA (making a correct password insufficient on its own).

What flows should I prioritise for credential stuffing protection?

Login forms are the primary target. But also protect: password reset flows (where different responses for valid versus invalid emails let attackers validate usernames), registration forms (where the same logic applies), and API authentication endpoints (which often lack the protections applied to web login forms). Prioritise in that order.

Related reading

Primary sources

OWASP Credential Stuffing Prevention Cheat Sheet: layered defence recommendations and detection guidance
New York State Attorney General: Business Guide for Credential Stuffing Attacks: regulatory investigation findings and control recommendations
Microsoft Security Blog: MFA blocks over 99.9% of account compromise attacks
Have I Been Pwned: Pwned Passwords API: recommended free tool for breached-password screening at registration and password change
IBM Cost of a Data Breach Report 2025: $4.44M global average breach cost, 241-day mean time to identify and contain
Verizon Data Breach Investigations Report 2025: stolen credentials involved in approximately one-third of all breach incidents; 88% of breaches within hacking patterns involved use of stolen credentials
23andMe Form 8-K/A SEC filing, December 2023: primary source confirming 14,000 accounts compromised via credential stuffing, 6.9 million users affected via DNA Relatives feature

Recent Posts

en_USEnglish
de_DEGerman fr_FRFrench es_ESSpanish nl_NLDutch it_ITItalian en_USEnglish