What Is a Credential Stuffing Attack?

Where the Passwords Come From

Credential stuffing attacks do not require the attacker to guess passwords. They use passwords that have already been stolen — leaked in previous data breaches from other websites and services. Lists of hundreds of millions of email addresses paired with their passwords circulate on dark web forums and paste sites. Significant breach datasets (LinkedIn 2012, Adobe 2013, RockYou2024, and thousands of smaller leaks) are freely available to anyone who looks for them.

The attack works because most people reuse passwords. A user who registered on a breached forum in 2014 with the same email and password they use for their business banking, their email account, or their company CRM is the typical target. The attacker does not need to know which services the user has accounts on — they simply try the credentials everywhere and see what opens.

How the Attack Works

**Collection** — The attacker obtains breach data, either downloaded from public sources, purchased, or compiled from multiple leaks. These datasets are often cleaned and deduped, with invalid entries removed, to maximise the hit rate.

**Automation** — Tools purpose-built for credential stuffing (Sentry MBA, Bulletproof, Openbullet, and custom scripts) take the breach list as input and fire login requests against the target website at high speed. A single attacker can test hundreds of thousands of credential pairs per hour against a single site. Residential proxy networks — built from compromised home devices — are used to rotate source IP addresses and avoid IP-based blocking.

**Success detection** — The tool monitors HTTP responses and page content to distinguish successful logins from failures. A successful login returns a different status code, redirect, or page content than a failed one. Hits — valid credential pairs — are logged for later exploitation.

**Exploitation** — Successful logins are used depending on the nature of the site. For an ecommerce site: fraudulent purchases using stored payment methods. For a financial service: account takeover and fund withdrawal. For a SaaS platform: data exfiltration or lateral movement. For any site with stored customer data: personal information harvested for further fraud.

Why Standard Login Pages Are Vulnerable

The fundamental problem is that a login form that accepts unlimited attempts from any IP address cannot distinguish a real user from an automated attack. Without rate limiting, an attacker can fire a million requests and receive a meaningful signal from each one. Without MFA, a correct password is sufficient to complete the login.

Several specific design decisions make sites more or less vulnerable:

**No rate limiting** — Allowing unlimited login attempts per IP address or per account in a short window is the primary enabler. A site that returns an error after five failed attempts within a minute forces the attacker to slow down dramatically, which makes large-scale credential stuffing economically unattractive.

**No account lockout or challenge** — After repeated failures, a secure login flow locks the account temporarily or presents a CAPTCHA challenge. Neither prevents all automated access, but both raise the cost significantly.

**Verbose error messages** — A login form that says "that email address is not registered" versus "incorrect password" allows an attacker to enumerate valid accounts before attempting passwords. A uniform "invalid email or password" message prevents account enumeration.

**No MFA** — Multi-factor authentication is the most effective single control. Even if an attacker has the correct password, they cannot complete login without the second factor. For accounts with financial or data value, MFA should be mandatory or strongly prompted.

Detection Signals

Credential stuffing attacks leave a pattern in logs that is distinct from normal user behaviour. Signs to look for:

- Spike in failed login attempts, particularly from IP addresses not previously seen - High volume of logins from a single IP address or a narrow IP range - Login attempts arriving at a machine-like constant rate rather than in human patterns - Logins from unusual geographies for your user base - Multiple failed attempts against a large number of different accounts (rather than one account being brute forced) - Successful logins immediately followed by account modification (email change, password change, payment method addition)

Web application firewalls and bot management solutions (Cloudflare, AWS WAF, Akamai Bot Manager) provide automated detection at the network layer. For sites without enterprise-grade infrastructure, application-level logging and alerting on login failure rates is the baseline.

Prevention Controls

Rate limiting on failed attempts per IP address and per account is the baseline. CAPTCHA or proof-of-work challenges introduced after a threshold of failures raise the cost of automation. MFA, even optional, removes the value of a successful credential match for users who have enabled it.

Checking submitted passwords against breach databases at login time — services like Have I Been Pwned provide an API for this — allows you to prompt users to change passwords that are known to be compromised, without storing the breach data yourself.

For related authentication attacks, [what is a brute force attack](/blog/what-is-a-brute-force-attack) covers the simpler variant where passwords are guessed rather than taken from existing leaks. [Two-factor authentication for website security](/blog/two-factor-authentication-website-security-uk) covers MFA implementation in more detail.

Yrzo AI's automated security assessment checks your login page for rate limiting controls, account lockout behaviour, error message enumeration risks, and MFA prompting across 54 security checks. Results in minutes. From yrzoai.dev.