Glossary · simply explained

Credential stuffing

Credential stuffing tests leaked passwords against your logins automatically — hitting wherever passwords are reused.

Credential stuffing is the automated testing of leaked credentials: attackers take billions of email-password pairs from past data breaches and try them against login pages via botnets — betting that people reuse passwords across services.

The hit rate is small, the volume enormous: fractions of a percent mean thousands of taken-over accounts across millions of attempts. To the operator the attack looks like normal login traffic — distributed across countless IP addresses.

Why classic defences fail

Unlike brute force, credential stuffing often tries just a single, correct pair per account — lockouts after failed attempts barely bite. Requests come from botnets with residential IPs and imitate real browsers; IP blocklists and simple rate limits come to nothing.

What works is the combination: bot management recognises automated clients by behaviour, checks against known leak databases flag compromised credentials at login, and MFA or passkeys devalue stolen passwords entirely.

How to spot ongoing stuffing

Rise in failed logins spread across many accounts and IPs.
Login successes from unusual regions or at atypical times.
Complaints about account takeovers without apparent phishing.
Conspicuous load on login and password reset endpoints.

Frequently asked questions about Credential stuffing

What is the difference to brute force?

Brute force guesses many passwords against one account; credential stuffing tests one already-leaked, correct pair per account — but against millions of accounts. That is why lockouts help against brute force but barely against stuffing.

Where do the tested credentials come from?

From past breaches of other services: such collections circulate by the billions in relevant forums, sorted and cheap. Every new leak anywhere on the net refills the supply — even if your own company was never affected.

How do I protect my user logins concretely?

Threefold: bot management in front of the login (detects automation by behaviour), checking incoming logins against known leak data with forced resets, and MFA or passkeys — so a correct password alone is no longer enough.

Does credential stuffing affect APIs too?

Yes, preferentially: login APIs for apps are faster and less conspicuous to hammer than web forms. API protection with rate limits, bot detection and anomaly analysis is therefore essential — including the mobile endpoints.

Are passkeys the solution against stuffing?

Largely yes: where no reusable password exists, there is nothing to stuff. Until all services have switched, bot defence and leak matching remain necessary — but passkeys remove the foundation of the attack model.