Home / Knowledge hub / Breached password check
Knowledge hub
Breached password check
Refusing passwords that already appear in public leaks.
What it means
A breached password check compares a password someone is choosing against lists of passwords that have already leaked in earlier breaches. If it matches, the application refuses it and asks for a different one, however long or complicated it looks.
NIST's digital identity guidance says a verifier should compare new passwords with a list of commonly used, expected or compromised values, and reject matches. That is considered more useful than forcing a mix of symbols.
Why it matters
Attackers do not guess at random. They take passwords from old leaks and try them on other sites, which is the idea behind credential stuffing. A password that is already in a leak is already in their list, so it will be tried early.
Blocking those passwords at the point of choice removes a large share of easy takeovers at low cost. It also shifts the effort off your users, who no longer have to remember arbitrary rules.
How it shows up
You add it where passwords are set or changed: sign-up, reset and change-password forms. Many teams use a range lookup service that receives only the first few characters of a hash of the password, so the full password never leaves your system. Others keep a local list.
The mistakes repeat. The check runs only at sign-up and never again. The full password is sent to a third party. The error message is vague, so users give up. Check all places a password can be set, decide what happens to existing passwords found in a leak, and test that the rule cannot be bypassed through the API.
Questions people ask
Breached password check, answered
Does it send our users' passwords to another company?
Not if built properly. Range-based services take only a short prefix of a hash, return the matching suffixes, and the comparison happens on your side. The full password or hash is never sent.
Alternatively, hold a local list and check it yourself.
Is it enough on its own?
No. It stops known passwords, not every weak or reused one. Combine it with rate limiting, MFA and monitoring for stuffing attempts.
It is one layer of a sensible password policy.
Should we check existing passwords too?
Yes, if you can do it safely. You only see a password when someone signs in, so check then and, if it matches a leak, ask them to change it.
Make the message clear and calm, so it is not mistaken for phishing.
Does it replace composition rules?
NIST advises against forced mixes of character types and regular scheduled changes. It recommends longer passwords, a block on known-bad ones and change on evidence of compromise.
A breach check supports that approach.
How do we test it?
Try a well-known leaked password at sign-up, in the change-password form and through the API. Confirm each refuses it with a useful message, and that no route skips the check.
Include the mobile and partner endpoints.
Related
Terms that sit next to this one
Credential stuffing
Trying passwords leaked elsewhere, because people reuse them.
Password policy
The rules on length, reuse and checking that decide which passwords you accept.
Password spraying
Trying a few common passwords across many accounts to stay under lockout limits.
Account takeover
An attacker ends up signed in as one of your real users.
Hashing
A one-way transformation, so a password can be checked but never read back.
Is this password already out there?
Credential stuffing and weak sign-in controls are part of what we test, and we prove findings by exploiting them. Each comes with the request and response. Book a pilot on one app.
Or start with a $199 pilot on one application: thirty days, success criteria agreed before day one, credited against the annual if you convert.