What is credential stuffing, and why rate limiting alone won't stop it

If you’ve ever seen a sudden spike of failed login attempts against a customer portal or booking system, there’s a good chance it wasn’t someone guessing passwords. It was credential stuffing — and understanding the difference matters, because the two require very different defenses.

It isn’t guessing. It’s replaying.

Every large-scale data breach that exposes email/password pairs eventually ends up circulating in bulk lists — sometimes billions of credentials, aggregated from breaches that have nothing to do with your business at all. Credential stuffing takes those known-real email/password combinations and tries them automatically against as many login pages as possible, on the (statistically very reasonable) bet that some meaningful percentage of people reuse the same password across sites.

The attacker isn’t trying to break your login system. They’re trying accounts your customers already have, hoping one of them reused a password you had nothing to do with leaking.

Why “just add rate limiting” doesn’t fully solve it

Rate limiting — blocking an IP address after too many failed attempts — is necessary, but it’s designed for a different threat model than what credential stuffing actually looks like:

• It’s distributed. Modern credential-stuffing tooling routes attempts through large pools of residential proxies or botnets, so no single IP ever crosses a suspicious threshold.
• It’s slow on purpose. “Low and slow” attacks deliberately stay under rate-limit thresholds, trading speed for staying invisible.
• It doesn’t touch the actual weakness. Rate limiting protects the login endpoint. It does nothing about the fact that the password being tried is, in fact, correct.

What actually helps

• Multi-factor authentication, even a basic implementation, defeats credential stuffing outright — a correct password stops being sufficient on its own.
• Checking new passwords against known-breached password lists at signup or reset, so customers aren’t unknowingly choosing a password that’s already in a public dump.
• Behavioral and device-based anomaly detection, which looks for patterns like “this login succeeded but from a device/location wildly inconsistent with this account’s history” rather than only counting failed attempts.
• Rate limiting and lockouts still matter — they raise the cost of the attack and catch the less sophisticated attempts — just not as the only layer.

The uncomfortable part of credential stuffing is that it doesn’t require any flaw in your system at all. The “vulnerability” is password reuse, which happens entirely outside your control — which is exactly why the fix has to happen on your side, not by hoping customers develop better password habits.