5 security checks that stop credential stuffing attacks
Five login checks that stop credential stuffing: rate limits, strong passwords, MFA, breached-password screening and monitoring for suspicious logins.
Credential stuffing is a bot replaying username and password pairs stolen from one site against the login of another. It works because people reuse passwords, and it needs no skill beyond running a script.
The scripts are off the shelf. An attacker with a breach dump, a proxy list and a stuffing tool can test thousands of pairs against your login form without writing any code.
At a 2% success rate, a 2017 estimate, one million stolen credentials take over twenty thousand accounts. The defense is on your login form, not in your users' habits.
Five checks catch most of it.
Five security checks that stop credential stuffing
They cover the volume, the reused password, the stolen password, and the attempts that slip through anyway.
1. Rate limit login attempts
Rate limiting is the first thing to turn on, because stuffing depends on volume.
Cap attempts per account and per IP over a minute, an hour and a day, and slow the client down with growing delays before you lock anything. An attacker who can only try a handful of passwords per account before the delay bites cannot run a list of millions.
2. Require strong passwords
Passwords are the keys to the account, and a reused one is a key the attacker already has. A customer who uses the same password everywhere is exposed the day any one of those sites leaks.
Require at least 12 characters with a mix of letters, numbers and symbols, and reject anything that appears on a common-password list.
3. Implement multi-factor authentication
MFA is the one control that breaks stuffing outright: a correct password on its own no longer logs anyone in.
Multi-factor authentication asks for two things: something the user knows, the password, and something they have, such as a device that generates a one-time code. Some factors are easier to bypass than others, so prefer an authenticator app or a hardware key over SMS.
The attacker now needs the second factor as well, and the codes expire quickly.
Step it up by risk rather than on every login: a known device gets through, a new device or a new country gets the prompt.
4. Check for compromised credentials
Check passwords against known breach lists at signup, at password change and at login, and force a reset when there is a match. A password that is already in a stuffing list is compromised whether or not your site has been attacked yet.
For your own staff, a password manager removes the reuse problem at the source: one vault, a different long password for every service, so one leaked password opens one account rather than all of them.
5. Monitor and alert on suspicious activity
Monitoring is what catches the attempts the first four checks let through, and it is harder to get right than it sounds.
A good monitor flags the things that do not fit: a login from a country the user has never been in, many accounts failing from one IP range, one device signing into many accounts, a sudden rise in failed logins across the site.
The alert should say what happened and how likely it is that a person was behind it, so an analyst can tell a traveller from a bot at a glance.
Repeated failures on one account, or a user who appears from a different country each time, are the two patterns worth paging on.
Where to start
Turn on rate limits and breach-list checks this week; they are cheap and they cut the volume at once. Add MFA for staff and high-value accounts next.
Then put monitoring on the login so you can see what the attackers try after the easy route closes.
This is not every control there is against an account takeover, but it is the set that stops the bulk of stuffing traffic.
A penetration test will tell you whether your login survives a stuffing run, and the other common types of attack are covered separately. To score every login from device, network and behaviour signals and let your rules allow, review or block it, see account takeover protection.