Credential Stuffing: How Reused Passwords Get Exploited

Many account takeovers involve no guessing at all. An attacker takes an email and password that leaked from one site and tries it on another. If you used the same password on both, they are in. Do that with millions of pairs, automatically, against a login page, and you have credential stuffing.

The attack is simple, cheap and persistent. It is also one of the easiest to defeat, which makes it worth understanding from both sides.

How credential stuffing works

OWASP defines credential stuffing as "testing username/password pairs obtained from the breach of another site." The workflow has four parts.

1. Acquire credentials. The attacker buys, trades or downloads lists of email and password pairs.
2. Target a login. They pick a site or API where accounts have value: streaming, retail with stored cards, airline miles, gaming, banking, cloud consoles.
3. Automate the attempts. A tool replays each pair against the login endpoint, routing traffic through many IP addresses so no single source looks noisy.
4. Monetise the hits. Working logins are used directly (buying goods, draining points), or sold as verified accounts, which fetch more than raw pairs.

The economics rest on password reuse. Verizon's 2025 DBIR research on infostealer data found that in the median case only 49% of a user's passwords across services were distinct from each other.

Success rates

Most attempts fail, and that is fine for the attacker. Shape Security reported success rates between 0.1% and 2% when stolen credentials were replayed against sites that had not themselves been breached. At 1%, a list of one million pairs yields roughly 10,000 working accounts. The cost of trying is close to zero, so even the low end pays.

Credential stuffing, password spraying and brute force

These three are often confused. OWASP's cheat sheet separates them cleanly.

Because stuffing tries each account only once or twice, per-account lockouts rarely trigger. That is the main reason it survives defences built for brute force. For the offline side of password attacks, where hashes are cracked rather than logins tried, see password cracking techniques.

Where the credentials come from

Combolists. These are text files of email and password pairs merged from many breaches, often deduplicated and sorted by domain. They circulate on forums and Telegram channels, some free, some paid. Many entries are years old.

Infostealer logs. This is the faster-growing source. An infostealer on one machine captures every password the browser saved, along with the URL each one belongs to. That URL pairing removes the guesswork: the attacker knows exactly which login page the credential works on, and the password is current. Stealer logs also carry session cookies, which let an attacker skip the login entirely. That is a separate attack, covered in session hijacking.

Phishing kits. Credentials typed into fake login pages are fresh and valid at the moment of theft.

To see whether a domain's employees or users show up in stealer logs, the stealer exposure check reports counts of infected employees and users and the login URLs that were captured.

The tooling, described defensively

Defenders benefit from knowing the categories of tooling, because each one leaves a different fingerprint.

The configs are shared and sold per target site, which is why a single popular service can see a surge of attacks after one config circulates. Proxy pools that route through residential connections are the reason simple IP blocking fails. Some of these networks are built from infected home devices, the same infrastructure described in what a botnet is.

Notable cases

23andMe, 2023. The company said attackers used credentials compromised elsewhere to access less than 0.1% of its 14 million customers, roughly 14,000 accounts. Through the opt-in DNA Relatives feature, those accounts exposed data on about 5.5 million DNA Relatives profiles and about 1.4 million Family Tree profiles. 23andMe responded by resetting passwords and requiring two-step verification for every account. The case shows how a small number of stuffed accounts can reach a much larger population through sharing features.

Roku, 2024. Roku reported that about 15,000 accounts were accessed using credentials stolen from other sources, followed by a second incident affecting about 576,000 accounts. In fewer than 400 cases attackers made purchases with stored payment methods. Roku said it was not the source of the credentials and turned on two-factor authentication for all accounts.

Snowflake customers, 2024. Mandiant's investigation of UNC5537 found the actor logged into Snowflake customer instances with credentials stolen by infostealers, some from infections dating back to November 2020. About 165 organisations were notified as potentially exposed, and at least 79.7% of the accounts used had prior credential exposure. Mandiant named three factors: no MFA, credentials never rotated, and no network allow lists. It is the same replay of stolen credentials at enterprise scale, fed by stealer logs. Our Snowflake breach guide has the full story.

Detection signals

Watch the login endpoint as a system, since individual accounts rarely look unusual.

• A rising failed-login ratio across the whole site, especially "unknown username" and "wrong password" failures together.
• Many distinct usernames per IP, device fingerprint or TLS fingerprint, even at low volume per source.
• Login attempts that skip the page. Requests straight to the login API with no prior page load, script execution or asset fetch.
• Fingerprint mismatches. A browser user-agent with a TLS or HTTP/2 fingerprint that belongs to a scripting library. OWASP names JA3 and HTTP/2 fingerprinting as useful signals.
• Traffic from hosting providers and known proxy ranges at unusual times.
• Successful logins followed by account changes: new email, new shipping address, new payment method, password change.
• Users reporting MFA prompts they did not trigger, which means their password worked somewhere.
• Credentials from your user base appearing in combolists or stealer logs.

Feed these into your SIEM and alert on site-wide trends.

How to defend against credential stuffing

For site and app owners

1. Require MFA, or at least trigger it for risky logins (new device, new location, hosting provider IP). OWASP calls MFA the strongest single defence.
2. Screen passwords against breach data. NIST SP 800-63B says verifiers "SHALL compare the prospective secret against a blocklist" that includes passwords from previous breach corpuses. The Pwned Passwords range API supports this with k-anonymity: the server sends only the first five characters of the password's SHA-1 hash and compares the returned suffixes locally, so the password never leaves your system.
3. Rate limit by more than IP. Limit by account, device fingerprint, subnet and ASN, and use progressive delays. NIST caps consecutive failed attempts on one account at 100. Our rate limiting guide covers the design.
4. Use device and connection fingerprinting to spot automation that rotates IPs.
5. Add a challenge on risk, and accept that CAPTCHAs alone are defeated by solving services.
6. Avoid user enumeration. Return the same response for a bad username and a bad password.
7. Notify users of new-device logins and password changes, so victims can act fast.
8. Offer passkeys. A passkey is bound to your site's origin and holds no reusable secret, so there is nothing for a combolist to contain. See passkeys explained.

For individuals

1. Use a unique password for every account, generated and stored by a password manager.
2. Turn on MFA everywhere it is offered, starting with email.
3. Switch to passkeys where available.
4. Check whether your email or passwords have leaked with Have I Been Pwned.
5. After a breach alert, sign out everywhere. The session kill switch lists where each major platform lets you revoke sessions and sign out of all devices.

Related guides

• Session Hijacking Explained
• Passkeys Explained
• Password Cracking Techniques
• The Snowflake Customer Breaches
• What Is an Infostealer
• Rate Limiting Explained
• Two-Factor Authentication Guide
• How Dark Web Monitoring Works