How Password Breach Checkers Work

The Paradox of Checking Compromised Passwords

To verify if a password has been compromised in a public data breach, a search utility must compare it against database lists containing billions of leaked credentials. However, sending your plaintext password over the internet to a third-party server to check if it is leaked defeats the entire purpose of password security.

How do professional breach checkers solve this problem? They use a mathematical model called k-Anonymity paired with cryptographic hashing.

According to Have I Been Pwned (HIBP), the service has tracked over 15 billion breached accounts across more than 900 data breaches as of 2026. Checking your credentials against this database regularly is a critical security practice.

---

Cryptographic Hashing: The First Step

A breach checker does not look up passwords in plaintext. Instead, it converts the input string into a cryptographic signature using a hashing algorithm like SHA-1.

A cryptographic hash function is a one-way mathematical transformation that converts any input data into a fixed-size output string. Key properties include:

• Deterministic: The same input always produces the same output.
• Pre-image resistant: It is computationally infeasible to reverse the hash to recover the original input.
• Collision resistant: It is computationally infeasible to find two different inputs that produce the same hash.
• Avalanche effect: A tiny change in input produces a completely different output.

For example, let’s take the password password123:

1. The password password123 is run through the SHA-1 algorithm.
2. The output is a 40-character hexadecimal string: 21BD87B39D59325D340C70A06E57C3CD43DF63B8.

Now consider password124 (a single character change):

• The SHA-1 hash becomes: 5A4C8E17C6B5A2C9F8D4E3B1A7C0D5F2E8B3A6C1

This dramatic difference demonstrates the avalanche effect—even a one-bit change produces an entirely different hash, making patterns impossible to detect.

While the hash is one-way, sending the full hash to a server is still a security risk. If an attacker intercepts the full hash, they can use offline databases to reverse it or associate it with your IP address. This is where k-Anonymity comes in.

---

Under the Hood: Hashed k-Anonymity

To check a password without exposing it, security APIs (such as Troy Hunt’s Have I Been Pwned service) implement k-Anonymity. Here is how the step-by-step process works:

graph TD
    A[User enters password] --> B[Generate SHA-1 Hash]
    B --> C["Split Hash: First 5 Characters (Prefix) vs Remaining (Suffix)"]
    C --> D[Send Prefix only to API Server]
    D --> E[Server finds all breached hashes starting with Prefix]
    E --> F[Server returns list of matching Suffixes and counts]
    F --> G[Local browser compares suffix to find a match]

1. Splitting the Hash

The browser splits the 40-character SHA-1 hash into two parts:

• Prefix: The first 5 characters (e.g., 21BD8).
• Suffix: The remaining 35 characters (e.g., 7B39D59325D340C70A06E57C3CD43DF63B8).

2. The API Request

The browser sends only the prefix (21BD8) to the API. Because the prefix is only 5 characters long, there are $16^5 = 1,048,576$ possible prefixes. The server receives the prefix and returns a list of all compromised suffixes in its database that start with that exact prefix, along with the number of times each suffix has been seen in breaches.

For example, the server might return:

• 7B39D59325D340C70A06E57C3CD43DF63B8: 3,829,102 times
• 8A41E7F29...: 12 times
• 9C51C8D33...: 1 time

3. Local Comparison

Once the browser receives this list of suffixes, it performs the final comparison locally on your computer. It checks if the suffix of your password’s hash is in the list. If it matches, the password is flagged as compromised.

---

Understanding k-Anonymity in Depth

k-Anonymity is a privacy model that ensures each query is indistinguishable from at least $k-1$ other possible queries. In the context of breach checking:

• When you send the 5-character prefix 21BD8, the server cannot determine which specific password you are checking.
• On average, each 5-character prefix maps to approximately 800-1,200 different hashed passwords in the HIBP database.
• The server sees only the prefix, which corresponds to hundreds or thousands of different possible full hashes.
• This means the server learns nothing about your specific password.

Practical Example of k-Anonymity in Action

Imagine the prefix 21BD8 matches 1,000 different breached hashes. When the server receives this prefix, it knows you are checking one of those 1,000 passwords—but it has no way to determine which one. Your query is effectively hidden among a crowd of 999 other possibilities.

This is fundamentally different from sending your full hash (which could be looked up directly) or your plaintext password (which would be completely exposed).

---

Why Is This Method Safe?

This approach ensures absolute privacy because:

• The API server never sees your password. It only sees the first 5 characters of the hash. It is mathematically impossible for the server to determine what your full password is from just 5 characters of a SHA-1 hash, as hundreds of thousands of different passwords share the same 5-character hash prefix.
• No queries travel in plaintext. The communication is encrypted via TLS (HTTPS), preventing man-in-the-middle interception.
• The local browser does the heavy lifting. The actual matching happens in your browser’s memory, ensuring that zero data leaves your local device beyond the anonymized prefix.
• No authentication is required. The HIBP API does not log IP addresses or require account creation, further reducing the privacy footprint.

Security Comparison Table

Method	What the Server Sees	Privacy Risk
Plaintext password	Full password	Critical — complete compromise
Full SHA-1 hash	40-character hash	High — hash can be reversed via rainbow table
5-character prefix	5 chars of hash	Minimal — cannot identify specific password
k-Anonymity + HTTPS	5 chars over TLS	Negligible — no meaningful data leakage

---

The Have I Been Pwned (HIBP) API

Troy Hunt’s HIBP is the most widely used breach database, and it powers many security tools including GeneratePass’s Password Breach Checker. Key facts about HIBP:

• Data sources: Over 900 breach datasets containing 15+ billion records.
• Update frequency: New breaches are added regularly, often within days of public disclosure.
• API design: Uses the k-Anonymity model described above for all password checks.
• Rate limiting: The public API limits requests to prevent abuse (1 request per 1.5 seconds for the password range endpoint).
• Open source: The API documentation and breach data models are publicly available for verification.

How GeneratePass Uses HIBP

GeneratePass integrates with the HIBP password range API using the following workflow:

1. Your password is hashed locally in your browser using SHA-1.
2. The 5-character prefix of the hash is sent to the HIBP API.
3. HIBP returns all matching suffixes from its breach database.
4. Your browser compares the full suffix locally.
5. The result is displayed entirely client-side — no password data ever leaves your device.

You can verify this yourself by opening your browser’s developer tools (F12), navigating to the Network tab, and observing that only 5 characters are transmitted to the API endpoint.

---

Limitations of Breach Checkers

While breach checkers are invaluable security tools, they have important limitations:

1. They Only Check Known Breaches

Breach checkers can only verify against databases that have been publicly disclosed. A password that has been compromised in an undetected or undisclosed breach will not be flagged. This is why generating truly random passwords is essential — even an unknown breach cannot compromise a password that an attacker cannot guess.

2. They Cannot Check Real-Time Threats

Breach databases are updated periodically, not in real-time. A password compromised today may not appear in the database for days or weeks. This is why breach checkers should be used as one layer of a broader security strategy, not as the sole defense.

3. They Cannot Replace Strong Passwords

If you use a weak password like password123, the breach checker will correctly flag it — but the real issue is the password itself. Always generate strong, random passwords using a Password Generator rather than relying on breach checkers to catch weak choices.

4. False Negatives Are Possible

Some password manager breach-checking features hash passwords differently or use subset databases. Always use a reputable tool that implements the full k-Anonymity protocol against the complete HIBP database.

---

Best Practices for Using Breach Checkers

1. Check all existing passwords when you first start using a password manager. This identifies accounts that need immediate password changes.
2. Check new passwords before deploying them. Use our Password Breach Checker to verify that a newly generated password has not appeared in any known breach.
3. Re-check periodically. As new breaches are discovered and added to databases, previously safe passwords may become compromised. Set a quarterly reminder to audit your credentials.
4. Combine with strength testing. A password that is not in any breach database is still weak if it has low entropy. Use our Password Strength Checker and Password Entropy Calculator alongside breach checking.
5. Enable breach alerts. Some password managers offer automatic breach monitoring that notifies you when a stored credential appears in a new breach. Enable this feature if available.

---

Frequently Asked Questions

Does sending my password hash to a server make it insecure?

No — when implemented correctly using k-Anonymity, only 5 characters of the hash are sent. With over 1 million possible prefixes, the server cannot determine which specific password you are checking. The full hash never leaves your device. You can verify this in your browser's Network tab.

What is the difference between k-Anonymity and sending a full hash?

Sending a full SHA-1 hash allows the server to look it up directly in a rainbow table and recover your password. k-Anonymity only sends 5 characters of the hash, which correspond to hundreds or thousands of different possible passwords. The server cannot determine which specific password you are checking.

Is the Have I Been Pwned API free to use?

Yes, HIBP offers a free API for password checking using the k-Anonymity model. There are rate limits to prevent abuse, but they do not affect normal usage. The service is maintained by security researcher Troy Hunt and is trusted by major password managers and security tools worldwide.

Can a breach checker detect zero-day breaches?

No. Breach checkers can only detect breaches that have been publicly disclosed and added to their database. A zero-day breach (one that has not yet been discovered) will not be detected. This is why generating random, high-entropy passwords is essential — even an unknown breach cannot yield a guessable password.

How often should I check my passwords against breach databases?

We recommend checking all passwords when you first adopt a password manager, then setting a quarterly reminder to re-check. You can also use automated breach monitoring features offered by many password managers. Generate a fresh password with our [Password Generator](/password-generator) whenever a breach is detected.