Credential Stuffing and Password Reuse Risk

Credential Stuffing and Password Reuse Risk

Twenty-two percent: that is the share of breaches in Verizon's 2025 Data Breach Investigations Report that started with a compromised credential rather than a software exploit.¹ Most of those compromised credentials were not cracked through brute force at all. They were stolen from one breached service and replayed automatically against hundreds of others, a technique called credential stuffing. This matters because credential stuffing sidesteps the entire entropy conversation this tool is built around; a password can carry 128 bits of theoretically perfect randomness and still fall to a stuffing attack if you reused it somewhere that already leaked. This page explains exactly how the attack works, why reuse rather than weakness is the enabling condition, and what actually stops it.

How credential stuffing actually works

An attacker starts with a list of username-password pairs pulled from a previous breach, sometimes numbering in the billions of entries.¹ Instead of guessing, automated bots simply replay each known-correct pair against the login pages of hundreds of other, unrelated services, betting that some fraction of users reused that same password elsewhere. Akamai has reported roughly 193 billion credential stuffing attempts occurring across the services it monitors in a single year.²

Why bots, not brute force

Because this attack replays credentials that are already verified correct somewhere, the bots do not need to guess anything. They need volume, automation, and enough distributed infrastructure, rotating IP addresses and browser fingerprints, to avoid the rate limiting that protects against a slower, manual brute-force attempt at the same login form.

A successful stuffing attempt looks identical to a normal login from the target service's perspective, since the credentials really are correct. That indistinguishability is what makes stuffing so hard to defend against with rate limiting alone; the traffic pattern only becomes suspicious once volume or velocity across many accounts reveals the automation behind it.

Why password reuse is the enabling condition, not the password's entropy

Credential stuffing changes what 'strong' means in practice. A password can carry enough entropy to resist any brute-force attack an attacker could ever mount, and NIST would rate it as effectively unbreakable by guessing, yet it still fails completely under credential stuffing if the same exact password was used on another service that later suffered a breach; the breach itself does not target password strength, it merely releases a correct credential that bots replay elsewhere.

Why entropy is not the variable that matters here

Credential stuffing does not care how strong your password is. It only cares whether the exact password it already has on file for you still works somewhere else. A password with 100 bits of entropy, generated randomly and impossible to brute-force in any practical timeframe, offers zero protection against stuffing the moment it is reused across two services and one of them is breached.³

This is precisely the gap raw entropy calculations cannot close. Entropy measures resistance to guessing; credential stuffing is not a guessing attack. The variable that determines whether you are vulnerable to stuffing is uniqueness across services, a property entirely independent of how many bits any single password carries on its own.

What actually stops credential stuffing

A unique password per service breaks the replay mechanism completely, since a leaked pair from one breach simply does not match the password used anywhere else. Multi-factor authentication adds a second layer that a stolen password alone cannot satisfy, stopping most stuffing attempts even when the underlying password happens to match.

The service side of the defense, and the reliable personal fix

NIST's current guidance formalizes part of this defense on the service side: verifiers SHALL screen new passwords against a blocklist of known compromised credentials, catching some reused, already-breached passwords at the point of creation rather than after an attack succeeds.⁴ On your side, the reliable fix is structural: a password manager that generates and stores a distinct password for every account removes reuse as a possibility entirely, and it costs nothing extra to confirm a generator actually reaches target entropy rather than relying on memory or discipline to maintain it manually. Trying to remember dozens of genuinely unique passwords without a manager is not realistic for most people, which is exactly why reuse remains so common despite widespread awareness that it carries risk.⁵

When to use this

Think about credential stuffing specifically whenever you catch yourself reusing a password, even a strong one, across more than one account. It is also the right lens for understanding why a breach at a service you barely use can still put your email or banking login at risk if you shared a password between them, especially for accounts you signed up for years ago and rarely think about now. A quick audit of your password manager for reused entries is a reasonable place to start closing that exposure.

Examples