A password can be stolen from one website and then used against another. This is called credential stuffing. The attacker hopes that people have reused the same email address and password. Because the password may be correct, a successful sign-in can matter more than a long list of failed attempts.
Understand the idea
Think about every entrance to the account. A service may have a website, a mobile application, an older email connection, and a recovery process. If only the main login has strong protection, another entrance may still accept the stolen password. Each route needs appropriate checks.
- Reuse
Credentials stolen elsewhere are tried against your service.
- Coverage
Find every route that accepts those credentials.
- Control
Apply suitable MFA, throttling, and abuse monitoring.
A practical example
For example, a membership service sees many failed sign-ins followed by a few accepted sessions. The team checks what those sessions did. One changed a recovery address and another exported member details. Resetting passwords helps, but the team must also end the unwanted sessions and reverse unauthorized changes.
What to do next
- Reduce password reuse. Encourage unique generated passwords and check new passwords against known compromised values using an appropriate privacy-preserving service or local blocklist.
- Add a stronger sign-in factor. Prefer phishing-resistant passkeys or security keys where supported. Protect registration and recovery so an attacker cannot simply register a new factor.
- Throttle across dimensions. Combine account, source, device, and service-wide signals. Provide a safe recovery route rather than allowing attackers to lock everyone out.
- Protect high-impact actions. Require fresh authentication or an appropriate additional check before exporting sensitive data or changing recovery and payment information.
How to check the result
Use approved test accounts to check the different login routes. Record which protections worked and whether support can help a real user recover access without weakening those protections.
We enabled MFA on the website. Are we finished?
Check the other access paths. A mobile endpoint or legacy protocol with weaker controls can leave an alternative route into the same account.
Sources and useful guides
The following resources provide background and more detailed guidance. Use the sections that match your service and situation.
