Home / Knowledge hub / Credential stuffing
Knowledge hub
Credential stuffing
Trying passwords leaked elsewhere, because people reuse them.
What it means
Credential stuffing takes usernames and passwords leaked in someone else's breach and tries them against your login. People reuse passwords, so a share of those pairs work. No bug in your code is involved anywhere.
The traffic looks ordinary. Attempts arrive slowly, from thousands of addresses, through browsers that behave like your customers. A small fraction succeed, and that is enough to pay for the run.
Why it matters
You cannot patch your way out of this one. You can only make the attempts expensive and the successes visible. The logins that hurt most are rarely customer accounts. They are staff accounts with broad permissions and no second factor.
Failed attempts cost you too. A long campaign locks real customers out, fills your support queue, and ruins your login numbers for a week. A successful attempt is genuine, so you will never find it by hunting for attacks. You find it by noticing where an account signed in from, then asking what that account can reach. That second question you can answer in advance.
How it shows up
Read the shape of the traffic rather than any single request. Failed logins spread thinly across thousands of accounts, attempts on usernames that never existed, and sign-ins from places your customers do not live are the usual tell.
Three controls do most of the work. Put a second factor on anything privileged. Count your limits per account as well as per address. Check every new password against known breached lists. OWASP recommends that last one first, and NIST asks verifiers to screen chosen passwords the same way. See also MFA and rate limiting.
Questions people ask
Credential stuffing, answered
Is credential stuffing the same as a brute force attack?
No. Brute force guesses password after password against one account until something works. Credential stuffing already holds real pairs from another company's breach and tries each one once.
That difference matters for your defences. Lockouts and slow-down rules built to catch repeated guessing often miss stuffing entirely, because each account only ever sees one attempt.
Does MFA stop credential stuffing?
It stops most of it, which is why OWASP puts multi-factor authentication first in its prevention guidance. The gap is coverage rather than strength.
Attackers go for the logins that skipped it: service accounts, admin accounts created before you turned it on, and the staff member who asked for an exemption. Check who is exempt this week, not who was exempt at rollout.
The passwords leaked from another company. How is this our problem?
Because the damage lands on your customers and your support team. Nobody whose invoices got read will care which breach the password came from.
You cannot stop the leak. What you own is the blast radius: what a stolen login is allowed to see, export or change once it is inside.
How do we tell whether we are being hit right now?
Count failures per account, not per address. A jump in failed logins spread across many accounts, together with attempts on usernames that do not exist, is the signature.
Volume from one address is rare now, because the attempts come through residential proxies that look like ordinary customers.
Should we force every user to reset their password?
Force it when you find successful logins you cannot explain, and tell people why you are asking. A silent blanket reset buys support calls and teaches nobody anything.
Screening new passwords against breached lists at the moment somebody sets one does more good. NIST specifically advises against making people change passwords on a timer for no reason.
Sources
Where this comes from
Related
Terms that sit next to this one
Brute force
Trying passwords or codes over and over until one of them works.
Account takeover
An attacker ends up signed in as one of your real users.
MFA
A second proof beyond the password, usually a code or a hardware key.
Rate limiting
Capping how often something can be attempted, per user or per address.
Authentication
Proving you are who you say you are. It answers one question only.
Their breach, your login screen.
Nothing here is a patch, so we test what a stolen login reaches: which records, which actions, which roles. That part you do control. Ask us to test one application for 30 days.
Or start with a $199 pilot on one application: thirty days, success criteria agreed before day one, credited against the annual if you convert.