Forem: Eden

How HaveIBeenPwned Checks Your Password Without Ever Seeing It

Eden — Fri, 17 Apr 2026 13:54:09 +0000

Maybe you've seen "check if your password has been breached" features scattered across the web. Maybe you've used haveibeenpwned.com yourself.

But there's an uncomfortable question sitting under all of it... how does a breach checking service verify your password against a database of billions of leaked credentials without you just... handing them your password?

The naive implementation would just be awful. You send your password to a server, the server checks it against a list, the server tells you the result. Congratulations! You've just handed a third party your plaintext password to "solve" a security problem.

I'm sure we both know the issue with that (at least I hope I do...).

The way HIBP does it is actually rather clever, and worth understanding. Both as a user and as a developer building anything that touches authentication.

Overview of K-Anonymity

K-anonymity is a privacy concept that's been around since the late nineties. A piece of data satisfies k-anonymity if it's indistinguishable from at least k-1 other pieces of data. In other words, you can't be singled out from a crowd of at least k people.

The classic example is medical records. If you release a dataset where every patient shares their age, postcode, and gender with at least k-1 other patients in the set, no individual record can be uniquely identified. The data is still useful, but the individuals are still protected.

Unfortunately, k-anonymity is susceptible to homogeneity attacks (where all k people share sensitive information, revealing a group) and background knowledge attacks (where an attacker uses additional information to narrow possibilities).

HIBP applies this same idea to password checking, and their implementation is surprisingly straightforward. Luckily for us, our passwords on HIBP aren't nearly as susceptible to these weaknesses.

Before we get into how, it's worth understanding what HIBP is. Troy Hunt (creator of HIBP) has spent years collecting password data from data breaches (like RockYou, LinkedIn or Adobe). All of these entries have been hashed, indexed and made queryable. The issue then becomes: "How do you check this data without exposing your own password?"

When you want to check if a password has appeared in a breach, you don't send the password. You don't even send a full hash of the password. You send the first five characters of its SHA-1 hash.

Say your password hashes to:

5BAA61E4C9B93F3F0682250B6CF8331B7EE68FD8

(in this case the password is password... don't judge I needed a good example)

You send 5BAA6 to the HIBP range API. HIBP responds with every hash suffix in their database that starts with those five characters, along with a count of how many times each one appeared in breach data.

You get back something like a list of hundreds of entries:

You then check whether your full hash suffix (1E4C9B93F3F0682250B6CF8331B7EE68FD8) appears in that list. If it does, and the count next to it is greater than zero, that password has been in a breach. The count tells you how many times.

The privacy guarantee here is k-anonymity. Any given 5-character SHA-1 prefix matches hundreds to thousands of different hashes in the HIBP dataset. HIBP's server receives your prefix and has no way of knowing which of those hashes you actually care about. Neither your password, nor its hash, ever leave your computer.

It's important to be honest here though... this method isn't perfect. You still end up sending the first 20 bits of your hash. There are 16^5 (~1 million) possible prefixes, so you often end up narrowing the results down to a couple hundred. This is a reasonable trade-off, but it certainly isn't perfect. It's k-anonymity, not zero-knowledge.

Isn't SHA-1 Broken?

SHA-1 is indeed a "broken" hashing algorithm (proven to be feasibly susceptible to hash collisions). For digital signatures, certificates and authentication, this is a serious problem.

In this use case though, it's not really important. You're not trying to store or protect this password on their servers. SHA-1 provides exactly what is required; a consistent, one way transformation to a fixed length string. K-anonymity is what's actually doing the privacy work, nobody is trying to reverse the hash or forge a hash collision.

That being said, never use SHA-1 (or any fast or broken hash) to store passwords (I'm looking at you). That's what bcrypt, scrypt, and Argon2 are for. The HIBP use case and the password storage use case are different problems with different requirements.

In Practice

Checking if passwords have been exposed in a breach is becoming an increasing concern, including organisations like NIST (the National Institute of Standards and Technology), that recommend checking new passwords against these breach lists.

shameless self promotion. This is the mechanism behind the breach detection in Bastion, the API I built. When you send a password to the endpoint, it is hashed on the worker, and only sends the first 5-characters of the SHA-1 hash to HIBP.

Checking out the free demo, or supporting me on Ko-Fi would mean the world to me :D Thank you for reading this far!!

If you're building anything that touches user credentials, breach checking via the range API (or my own COUGH COUGH) is low-effort, high-value. There's no excuse not to.

Why Your Signup Form Is Less Secure Than You Think (And How to Fix It)

Eden — Wed, 08 Apr 2026 04:22:00 +0000

You've seen those password rules. "Must be more than 8 characters. Must include a symbol. Must contain a number." They have good intentions, but have one fatal flaw. Us.

You would hope everyone uses something more than "P@ssword1" (or any of its many variants), but unfortunately, you'd be wrong.

Photo of the Bastion Demo that shows the password: "P@ssword1" being included in 442,781 known breaches.

So what is actually happening, and what can we do about it?

These "traditional" password rules weren't wrong to exist, but they focus on the wrong thing. Primarily, they focus on what makes a password look complex, rather than what a machine considers "complex".

That'd be fine, except most attacks don't work that way. Most passwords susceptible to this are brute forced, rather than recreated from over your shoulder.

NIST (the National Institute of Standards and Technology) actually updated their guidelines recently, recommending longer minimum lengths and preventing the use of common, expected and compromised passwords.

Most people, understandably (my younger self included), took shortcuts, prioritising short, simple passwords (usually for memorisation) over complexity.

Now databases are littered with these "valid", but trivial passwords that can take machines minutes, if that, to crack (obviously this is still better than NO rules... "123456" has been found an embarrassingly large number of times in breaches).

Photo of the Bastion Demo that shows the password: "123456" being included in 209,972,844 known breaches.

What we actually want to measure is the complexity of guessing (or brute forcing) said password, which is a very different problem.

zxcvbn (I only just realised now, while writing this, that it's the bottom row of the QWERTY keyboard... never clicked when I was using it for the API ;-;) was built by Dropbox and takes a very different approach to password strength. Rather than checking for these rules, it uses more complex pattern matching to estimate the number of guesses it would take to crack a password.

zxcvbn checks against things like:

Most common passwords, names, and dates
Keyboard patterns (qwerty, 123456, and even zxcvbn)
Common substitutions (@ for a or 3 for e)
Repeating/reversed characters or strings (aaabbbccc)

The result is a score, crack times against multiple scenarios (throttled online, offline fast hash, etc.), as well as warnings and suggestions for weaker passwords.

Bad password example:

Photo of the Bastion Demo that shows the password: "P@ssword1" being included in 442,781 known breaches. It also shows the estimated crack time ranging from 4 days to less than a second. Below that is a warning with a list of suggestions.

Good password example:

Photo of the Bastion Demo that shows the password: "correct-horse-battery-staple" being included in no known breaches. It also shows the estimated crack time ranging from centuries to 57 years.

In Practice:

Here's what it looks like to actually check a password against an API that uses zxcvbn:

Request:

POST https://bastion.eande171.workers.dev/v1/evaluate 
BODY { "password": "P@ssword1" }

Response:

{
    "score": 1,
    "strength": "Weak",
    "entropy_bits": 13.425215903299385,
    "crack_times": {
        "online_throttled": "4 days",
        "online_unthrottled": "18 minutes",
        "offline_slow_hash": "1 second",
        "offline_fast_hash": "less than a second"
    },
    "warning": "This is similar to a commonly used password.",
    "suggestions": [
        "Add another word or two. Uncommon words are better.",
        "Capitalization doesn't help very much.",
        "Predictable substitutions like '@' instead of 'a' don't help very much."
    ]
}

This response gives you a lot of information to work with. The score and strength fields give you a numerical and human-readable version of the password strength.

An attacker with throttled attempts would find this password in 4 days (likely because the form would start rejecting too many attempts). This drops to 18 minutes without any throttling, and if they got access to the database, they could calculate it in no time at all.

The warning and suggestion fields are an addition given to weak passwords to give users clear, actionable feedback to improve the quality of their passwords.

This can be compared to a password (or passphrase), which is just a little bit longer:

Request:

POST https://bastion.eande171.workers.dev/v1/evaluate 
BODY { "password": "correct-horse-battery-staple" }

Response:

{
    "score": 4,
    "strength": "Very Strong",
    "entropy_bits": 64,
    "crack_times": {
        "online_throttled": "centuries",
        "online_unthrottled": "centuries",
        "offline_slow_hash": "centuries",
        "offline_fast_hash": "57 years"
    },
    "warning": null,
    "suggestions": null
}

This fills me with much more confidence, knowing that even if someone did get access to a database, it would take them 57 years (or possibly centuries) to crack it (unless it's stored in plain text... but that's a separate issue- although just as bad).

Password rules certainly aren't useless, but genuine protection requires measuring complexity, not enforcing arbitrary rules. zxcvbn (still can't believe I didn't get that) gives you a way to do that without reinventing the wheel.

Unfortunately, this is only one half of the problem... what happens if a password is strong but is already in a breach? It's more common than you think.

If any of you made it to this bit... THANK YOU!!! If you want to poke around the API I made for this exact purpose, you can find it here. It would really mean a lot if you could check it out (even just the free/demo versions).