Credential stuffing and password reuse: a practical defence guide
Credential stuffing does not guess every password. It reuses credentials already exposed elsewhere. The defence is a repeatable system of unique passwords, strong recovery and a second factor.
What credential stuffing is
Credential stuffing is an automated account-takeover technique. Attackers take email-and-password combinations exposed by one service and try them at many unrelated services. The attack works because people reuse the same password or a predictable variation. The target does not need to suffer its own breach; it only needs an account whose credential was reused from somewhere that did.
This differs from brute force, which guesses many passwords for one account, and from phishing, which persuades a person to disclose or approve something. The practical result can look similar: unfamiliar sign-ins, changed recovery details, fraudulent purchases or messages sent from the account.
Why one reused password creates a chain reaction
Email is commonly the first objective because it receives password resets. A reused email password may let an attacker reset shopping, social, work and financial accounts. Device accounts and mobile carriers can extend the chain. A small forum breach can therefore become a high-consequence takeover when the same secret protects a primary inbox.
A strong-looking password is not enough if it is reused. Length and complexity help against guessing, but uniqueness contains the damage from a breach. The safe target is one randomly generated password per service, stored in a password manager rather than remembered through patterns.
Warning signs to treat seriously
- A sign-in alert from a location or device you do not recognise.
- Password-reset or 2FA messages you did not request.
- A recovery email, phone number or forwarding rule that changed.
- New sessions, app passwords, API tokens or connected applications.
- A successful login using an old password after another service disclosed a breach.
One alert does not prove credential stuffing, but unexplained access should trigger a controlled response rather than a single password change.
What to do after suspected reuse
- Use a trusted, updated device. If compromise is possible, do not perform recovery on the suspect device.
- Secure the primary email account first, then device and financial accounts.
- Change the reused password everywhere it appears. Generate a different random password for every service.
- Review sessions, recovery methods, forwarding rules, API tokens and connected apps.
- Enable TOTP, passkeys or a hardware security key where supported. Save recovery codes in an encrypted location.
- Contact the affected service about transactions or identity changes and retain its official incident records.
If years of credentials need changing, work from highest consequence to lowest. A controlled vault migration can help preserve access while replacing the reused set.
How a vault changes the economics of the attack
A vault makes unique credentials practical. The owner remembers one strong master password while the manager generates and stores random per-site passwords. Autofill can reduce manual typing and, when domain matching is accurate, may make an unexpected domain easier to notice. HIBP-backed checks can flag known exposure signals so a user can prioritise rotation.
IronVault stores credentials in the same zero-knowledge encrypted life vault as TOTP records and recovery notes. Vault contents are encrypted on the client; the master password and derived vault key are not sent to the server. See the security architecture and the broader encrypted life vault guide for the full workflow.
Add a second factor that survives recovery
TOTP or a hardware key can stop many password-only logins, but the recovery path matters. An attacker who controls email may bypass a second factor through account recovery. Keep recovery email and phone details current, remove old devices, and store one-time backup codes safely. The guide to storing 2FA codes explains the convenience and separation trade-offs.
What this does not solve
Unique passwords and 2FA do not make every takeover impossible. Malware may steal an unlocked session or capture a secret after decryption. Phishing may trick a person into approving a request. SIM swapping may defeat SMS, a weak support process may reset an account, and a malicious browser extension may observe form data. Some services also offer no strong second factor.
A password manager is therefore one layer in an account-security system. Keep devices updated, limit extensions, prefer app-based or hardware factors over SMS, review active sessions and use service-specific recovery controls. Learn more about what zero-knowledge cannot protect on its own.
A monthly containment routine
- Review weak, reused and known-exposed credentials.
- Rotate the highest-consequence accounts first.
- Remove sessions and connected apps you no longer use.
- Test one recovery code without consuming the only copy.
- Check that the primary inbox has no unknown forwarding rule.
- Confirm the vault can unlock and sync on the devices you actually need.
Credential stuffing succeeds at scale because reuse is common. A boring, repeatable routine of unique secrets, second factors and recovery checks removes that advantage one account at a time.
Back to IronVault home · Credential Stuffing and Password Reuse: Defence Guide