Breached password checks: Using Have I Been Pwned safely at home and in login flows

Passwords that have already leaked in a data breach are the first ones attackers try, and most people and many login systems have no way of knowing a password is on those lists until an account is taken over. Have I Been Pwned (HIBP) answers two separate questions: whether an email address appears in a known breach, and whether a particular password has appeared in breach data (Pwned Passwords). This guide explains both for individuals, then shows developers and identity teams how to build breached-password checks into sign-up, password change and sign-in using the k-anonymity range API, how to audit Active Directory against the offline NTLM list, and how this meets the blocklist requirement in NIST SP 800-63B Rev. 4. The Password Policy Template covers wider password policy; this page goes deep on breach checking.

Key takeaways

• Two different services, two different questions. An email search tells you which breaches included your address; Pwned Passwords tells you whether a password has been seen in breach data, without linking it to any person.
• You never send the password. The range API takes only the first five characters of the password's SHA-1 hash and returns matching suffixes; the final comparison happens on your device or server.
• NIST now requires a blocklist. SP 800-63B Rev. 4 (final, July 2025) says verifiers SHALL check new and changed passwords against a list of commonly used, expected or compromised values, and SHALL force a change when there is evidence of compromise.
• Check at set time and sign-in time. A password that was clean when chosen can appear in a breach next year; checking at sign-in and prompting a change closes that gap.
• A breach check supports MFA, it does not replace it. Credential stuffing at 23andMe in 2023 used passwords reused from other breaches against accounts that mostly lacked MFA.

For individuals: what HIBP tells you and what to do

Checking your email address

Enter your email address on haveibeenpwned.com to see the breaches it appeared in and what data each breach exposed. HIBP's FAQ explains a few points that often confuse people:

• Breach records are historical: changing your password does not remove the entry, because the breach happened. HIBP offers an opt-out that hides an address from public search.
• Pastes are not always breaches: a paste is data posted on a public site; appearing in one does not automatically mean an account was compromised, but it is worth reviewing.
• Sensitive breaches are hidden: breaches where being listed could harm someone are visible only to the verified owner of the address after signing in.
• Notify Me: sign up to be emailed if the address appears in a future breach; notifications only go to the address being monitored.

If your address shows up

1. Look at what leaked. If the breach included passwords, HIBP's advice is to stop using that password.
2. Change it everywhere you reused it, not just on the breached site. Reuse is what turns one breach into many account takeovers.
3. Turn on MFA on email, banking and any account that can reset others.
4. Use a password manager so every site gets a unique password; many managers and browsers can also warn you about breached passwords. See the Password Managers Explained for Everyone Guide.
5. Watch for follow-up phishing that quotes the breached data back to you to seem legitimate. See the What to Do After a Data Breach Guide.

Checking a password safely

The Pwned Passwords search on HIBP hashes your password in the browser and sends only the first five characters of the hash, so the service never receives the password or its full hash. A result with a count means the password has been seen in breaches and should not be used anywhere. A zero result does not make a password strong: it only means it is not in the corpus. Be wary of any other site that asks you to type a password into a "breach checker" without explaining how it protects it.

How the Pwned Passwords range API works

The flow for a login service: compute SHA-1 of the candidate password in upper-case hex, send the first five characters, and search the returned suffixes for the remaining 35. If found, the count shows how often it has appeared. Padding hides the exact response size, which otherwise could hint at which prefix was requested on an observed connection.

The email search is a different API: the breachedAccount endpoint at haveibeenpwned.com/api/v3 needs a paid API key in the hibp-api-key header and a user agent that identifies your application (requests without one get HTTP 403). Rate limits depend on the subscription and are enforced with HTTP 429 and a retry-after header. Domain-wide search requires you to verify control of the domain first.

Building breached-password checks into login flows

Where to check

Implementation steps

1. Decide online or offline. The range API is simplest and always current. An offline copy suits air-gapped systems, very high volume, or a policy against any outbound call from the authentication path.
2. Fail open, with logging. If the API is unreachable, allow the password and log the miss; do not block registrations because a third-party service is slow. Set a short timeout.
3. Set a threshold. Many teams reject any count above zero; others reject above a small count to reduce friction. NIST does not set a number; it requires the blocklist to cover commonly used, expected or compromised values.
4. Add context words. Supplement the breach list with your product name, company name and the user's own name, as SP 800-63B lists context-specific words among examples.
5. Write a helpful message: "This password has appeared in a data breach elsewhere, so attackers may try it. Please choose a different one." Never imply the user's account here was breached.
6. Test: use known breached test values in a pre-production environment, confirm the full hash and password never appear in logs, and test the timeout path.
7. Roll back: put the check behind a feature flag so it can be disabled without a deployment.

Everything else NIST SP 800-63B Rev. 4 asks of password verifiers

• Length: at least 15 characters for passwords used as a single factor; at least 8 where the password is only part of multi-factor authentication; support at least 64.
• No composition rules and no periodic changes, but force a change on evidence of compromise, which a breach match is.
• Allow password managers and autofill, and pasting should be permitted.
• No hints and no security questions when choosing a password.

The UK NCSC gives aligned advice: use a deny list, do not force regular expiry, do not impose complexity rules, and where you cannot block at creation, search your password database for hashes of deny-listed passwords.

Auditing Active Directory and Microsoft Entra

• Active Directory: the NTLM version of Pwned Passwords allows an offline comparison of AD password hashes against breach data. Treat this as a privileged operation: extracting hashes requires domain replication rights, so run it on an isolated, approved host, keep results encrypted, and delete working copies. Force a change at next logon for matches.
• Microsoft Entra Password Protection: blocks weak passwords at change time in Entra ID and, with DC agents, in on-premises AD DS. Microsoft states its global banned list comes from Entra security telemetry, not third-party breach data, and the custom list holds up to 1,000 terms. It normalises substitutions (0 to o, $ to s), matches within an edit distance of 1, and requires a score of 5 points. It complements, rather than duplicates, a Pwned Passwords check.

Decision guidance

• Small website or SaaS start-up: call the range API at registration, password change and sign-in, reject any match, and fail open. It costs nothing, needs no key and takes a few dozen lines of code. Spend the saved effort on offering passkeys or MFA.
• Large consumer platform: consider an offline copy to remove the external dependency from the sign-in path and to control latency, with a scheduled refresh. Measure friction: if rejections at sign-up cause abandonment, improve the message and suggest a password manager or passkey rather than raising the threshold.
• Workforce identity on Microsoft: Entra Password Protection at change time plus a periodic NTLM audit of AD. If you also run an identity provider in front of applications, check there too, because it sees passwords that AD does not.
• Regulated or government systems: document the blocklist source, refresh frequency and threshold as evidence for SP 800-63B and IA-5(1) assessments.
• Passwordless roadmap: breach checks are a bridge, not a destination. Every account moved to passkeys removes a password from the reach of credential stuffing entirely; see the Passwordless and Passkeys Guide.

Security of the check itself

The check sits in the most sensitive code path you have, so build it carefully. Hash in memory and discard the plaintext immediately after verification; do not pass the password to an asynchronous job or queue for checking later. Pin the API host name in configuration rather than accepting it from user input. If you cache range responses to cut latency, cache by prefix only and expire entries so newly added breach data is picked up. For the offline copy, verify the download completed for every prefix and keep the file on the authentication servers with read-only permissions; it contains no personal data, but tampering with it could silently disable the check.

Where identity fits

Breach checks are written for human passwords, but service accounts and shared application passwords in directories are often older and weaker than anything a person uses, and they are excluded from user-facing checks. Include them in the AD NTLM audit, and where a service account still uses a password, move it to a managed account type or a vaulted, rotated credential. See the How to convert AD service accounts to gMSA page and the Password Security Guide.

Detection and measurement

• Log matches, not passwords: record that a breached-password match occurred, the flow (registration, change, sign-in) and the user identifier; never log the password, hash or prefix.
• Watch for stuffing: bursts of failed sign-ins across many accounts from rotating IP addresses, and a rising share of sign-ins with breached passwords. See the Password Spraying and Credential Stuffing Defence Guide.

Lessons from incidents

At 23andMe in 2023, attackers used email and password pairs leaked from other sites to sign in to more than 18,000 accounts, and the DNA Relatives feature then exposed data on almost 7 million people. Passwords needed only eight characters, fewer than 22 percent of customers used MFA or single sign-on, and over a million login attempts in a day went unnoticed. Breached-password checks at sign-in, rate limiting and MFA would each have reduced the impact. See the 23andMe credential stuffing breach 2023.

Common failure patterns

• Checking only at registration: old passwords that later appear in breaches stay in use for years.
• Sending full hashes or passwords to a third party: only the five-character prefix should leave your system.
• Logging the hash prefix with the user ID: this rebuilds most of the privacy the range API was designed to provide.
• Failing closed: an outage at the API blocks every new user.
• Telling users "your account was breached": a match means the password was seen elsewhere, and alarming wording drives support calls.
• Treating a clean result as strong: a password absent from the corpus can still be short or guessable.

Framework mapping

Practitioner checklist

• Check new and changed passwords against Pwned Passwords plus a context word list.
• Check at successful sign-in and require a change on a match.
• Use Add-Padding: true on range API calls.
• Fail open on API errors, with logging and a short timeout.
• Never log passwords, hashes or hash prefixes.
• Run a scheduled NTLM audit of Active Directory on an isolated host, service accounts included.
• Enable Entra Password Protection with a custom banned list for Microsoft identities.
• Drop complexity rules and periodic expiry in line with SP 800-63B and NCSC.
• Pair breach checks with MFA and credential stuffing detection.

Standards and references

• NIST: SP 800-63B Rev. 4 Authentication and Authenticator Management
• NCSC: Password policy, updating your approach
• Have I Been Pwned: API v3 documentation
• Have I Been Pwned: Pwned Passwords
• Have I Been Pwned: FAQs
• Have I Been Pwned: Pwned Passwords Downloader
• Microsoft Learn: Eliminate bad passwords using Microsoft Entra Password Protection

Related NHI Mgmt Group resources: Password Policy Template · Password Security Guide · Password Spraying and Credential Stuffing Defence Guide · What to Do After a Data Breach Guide