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.

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.

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.

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 & 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.

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.
• The local browser does the heavy lifting. The actual matching happens in your browser’s memory, ensuring that zero data leaves your local device.

Summary of Secure Checking

When using a modern security toolkit like GeneratePass, you can inspect your browser’s network tab. You will see that only the 5-character prefix is sent to public breach APIs. This balance of local computation and hashed network queries is what makes browser-based security checkup tools incredibly secure and auditable.