A practical reading of the OWASP Credential Stuffing Prevention Cheat Sheet. A stolen username and password only works if that password is still accepted here, and if nothing else is asked for.
Primary source: OWASP Credential Stuffing Prevention Cheat Sheet. Use it with the Multifactor Authentication Cheat Sheet.
Multi-factor authentication is the control. A lockout that freezes the account only helps the person trying passwords against it.
Stop the reused password
| Topic | Key points |
|---|---|
| MFA | Require a second factor at login. A stolen password on its own should not open the account. |
| Factor choice | Prefer a passkey or an authenticator app. SMS is weaker. Email as a second factor shares an inbox people reuse. |
| Breached passwords | Reject a known-breached password when the account is created and when the password is changed. |
| After a breach | When a new breach includes this user, require a reset and the second factor before the old password works again. |
| Step-up | Ask for the second factor again before a password, email or payout change. |
| Passkeys | Offer a passkey where you can, so there is no password to replay. |
Slow the automation
| Topic | Key points |
|---|---|
| Throttle | Slow repeated failures by account, address and device. Do not hard-lock the account after a few tries. |
| Signals | A new device, an unexpected country or a burst of failures is a reason to demand the second factor. |
| CAPTCHA | Use a challenge to slow a burst of attempts. It does not replace a second factor. |
| Messages | Keep the failure text the same for an unknown user and a wrong password. |
| Alerts | Do not email the user about every wrong password. Do tell them when the password was right and the second factor failed. |
| Last login | Show when the account last signed in, and a rough location, so the owner can spot a surprise. |
| Session | Issue a new session only after the second factor succeeds. Do not trust the session from before that check. |
| Logs | Record the account, the source and the result. Do not log the password or the one-time code. |
What a test should show
- A correct password from a known breach is not enough to sign in.
- A burst of failures slows down and does not permanently lock the account.
- The user is told when the password was right and the second factor was wrong.
- Failure messages do not reveal whether the username exists.
- Changing the password or the email address asks for the second factor again.
- Passwords and one-time codes are absent from application logs.
Ready to strengthen your security?
Talk to our consultants about your penetration testing requirements, or get a fast, transparent quote.