Have I Been Pwned Checker and k-Anonymity: How Your Password Check Stays Private

What Is Have I Been Pwned and Why Does It Matter?

If you've ever wondered whether your email address or password has turned up in a data breach, you've probably landed on Have I Been Pwned (HIBP) — the free breach-notification service built by Australian security researcher Troy Hunt. Since launching in 2013, the platform has indexed over 14 billion compromised accounts sourced from hundreds of data breaches, making it one of the most comprehensive breach databases available to the public.

But here's the question that stops a lot of security-conscious Australians in their tracks: if you're checking whether your password has been leaked, doesn't that mean you're sending your password to someone else's server? That's a completely fair concern — and it's exactly the problem that k-anonymity was designed to solve.

Understanding k-Anonymity: The Privacy Model Behind the Check

k-anonymity is a privacy concept originally developed in the context of data publishing, but HIBP applies a clever implementation of it to password checking. The core idea is simple: you should be able to verify whether your password appears in a breach database without the service ever learning what your actual password is.

Here's how it works in practice when you use HIBP's Pwned Passwords feature:

• Your browser or application takes your password and runs it through the SHA-1 hashing algorithm, converting it into a 40-character hexadecimal string.
• Only the first five characters of that hash are sent to the HIBP API.
• The API returns a list of all hash suffixes (the remaining 35 characters) that begin with those five characters — typically hundreds of results.
• Your local application then checks whether your full hash appears anywhere in that returned list.
• If it does, your password has been seen in a breach. If it doesn't, you're clear.

At no point does HIBP receive your full password or even your full hash. The server only ever sees a five-character prefix, which could correspond to hundreds of thousands of different passwords. That's the k-anonymity guarantee: your query is indistinguishable from many others, protecting your privacy even from the service you're querying.

Why SHA-1? And Is It Secure Enough?

SHA-1 is a cryptographic hash function that produces a fixed-length output regardless of input size. While SHA-1 is considered cryptographically broken for digital signatures and certificate purposes — meaning collisions can be engineered — it remains entirely appropriate for password hashing in this specific context.

The reason is straightforward: HIBP isn't using SHA-1 to protect your password from being reverse-engineered by a determined attacker with your hash. It's using it as a consistent fingerprinting mechanism so that both your local device and the HIBP database can refer to the same password in the same way, without transmitting the plaintext.

For users who want an extra layer of assurance, HIBP also supports NTLM hashes in its Pwned Passwords API, which is particularly useful for enterprise environments running Windows Active Directory. As of early 2026, the Pwned Passwords dataset contains over 10 billion unique hashed passwords sourced from real-world breaches.

The HIBP Pwned Passwords API: A Technical Walkthrough

Developers integrating HIBP into their own applications can use the Pwned Passwords API directly. The endpoint is straightforward:

GET https://api.pwnedpasswords.com/range/{first5HashChars}

A response looks something like this:

0018A45C4D1DEF81644B54AB7F969B88D65:1
00D4F6E8FA6EECAD2A3AA415EEC418D38EC:2
011053FD0102E94D6AE2F8B83D76FAF94F6:1
...

Each line contains a hash suffix followed by a colon and a count — the number of times that exact password has appeared in breach data. Your application concatenates the five-character prefix with each suffix, then checks whether the resulting 40-character hash matches the SHA-1 hash of the password you're checking.

This design means HIBP's servers are genuinely unable to log which specific password you checked. Even if their entire request log were subpoenaed or leaked, it would only reveal that someone queried a particular five-character prefix — information that's meaningless without knowing which of the hundreds of matching suffixes the user actually cared about.

Real-World Applications: Where k-Anonymity Password Checking Is Used

The k-anonymity model pioneered by HIBP has been widely adopted across the security industry. Here are some notable implementations you might already be using without realising it:

• Google Chrome and Microsoft Edge both use HIBP's Pwned Passwords API (or equivalent internal databases using the same model) to warn users when a saved password appears in a known breach.
• Apple's iCloud Keychain introduced a similar feature called Security Recommendations, which flags reused and compromised passwords using privacy-preserving techniques.
• 1Password integrates directly with HIBP's API to flag Watchtower alerts when stored passwords have been pwned.
• Bitwarden, the open-source password manager popular among Australian privacy advocates, offers an optional HIBP integration for breach checking.
• Many Australian businesses and government portals now use HIBP's domain breach notification service to alert employees when corporate email addresses surface in breaches.

How to Use Have I Been Pwned Yourself

You don't need to be a developer to benefit from HIBP. Here's how everyday Australians can use the service in 2026:

Checking Your Email Address

Head to haveibeenpwned.com and enter your email address. The site will tell you whether that address appears in any known data breach, which breach it came from, and what types of data were exposed — passwords, phone numbers, physical addresses, and so on. Your email address is sent to HIBP's servers for this check, but that's a deliberate trade-off: email addresses are identifiers, not secrets, and the service is explicitly designed to help you understand your exposure.

Checking a Specific Password

Visit haveibeenpwned.com/Passwords and type in a password. The k-anonymity model kicks in here: only the first five characters of the SHA-1 hash are transmitted. You'll see how many times that password has appeared in breaches. Even a count of 1 is a strong signal to change it immediately.

Setting Up Breach Notifications

You can register your email address to receive automatic notifications whenever it appears in a newly processed breach. This is particularly valuable for Australians who may have had their data exposed in breaches they're not yet aware of — including the Optus breach of late 2022, the Medibank breach, and numerous smaller incidents that continue to surface in 2026.

Limitations and Honest Caveats

k-anonymity is a robust privacy model, but it's worth understanding what it doesn't guarantee:

• It doesn't protect against timing attacks at scale. A sophisticated adversary monitoring network traffic at the infrastructure level could theoretically correlate query timing with user activity, though this is an extreme threat model irrelevant to most users.
• It doesn't mean your password is safe if it's not in the database. Absence from HIBP's breach data doesn't mean a password is strong or unguessable — only that it hasn't appeared in a breach dataset that HIBP has indexed.
• The database isn't exhaustive. HIBP indexes breaches that have been publicly disclosed or shared with Hunt's team. Private, unreported breaches won't appear.
• Hashing doesn't protect weak passwords from dictionary attacks. If your password is password123, it will absolutely appear in HIBP's database — but even if it didn't, it would still be trivially guessable.

Why This Matters for Australian Businesses

Under the Australian Privacy Act 1988 and the Notifiable Data Breaches scheme administered by the Office of the Australian Information Commissioner (OAIC), organisations holding personal information have legal obligations to protect that data and notify affected individuals of eligible data breaches. Integrating HIBP's API into employee onboarding and password reset workflows is a practical, low-cost measure that helps reduce credential-stuffing risk.

The Australian Cyber Security Centre (ACSC) has consistently recommended that organisations implement controls to prevent the use of known-compromised passwords. HIBP's k-anonymity API is one of the most straightforward ways to implement this recommendation without introducing new privacy risks.

Setting Up k-Anonymity Password Checking in Your Own Systems

For developers and IT administrators, implementing HIBP's Pwned Passwords API is genuinely straightforward. Libraries exist for virtually every major language:

• Python: The pwnedpasswords package handles the hashing and API call in a single function.
• JavaScript/Node.js: Multiple npm packages implement the full k-anonymity flow.
• PHP: Composer packages are available, and the raw implementation is under 20 lines of code.
• PowerShell: Particularly useful for Windows environments checking Active Directory passwords against the breach database.

Troy Hunt also maintains a partnership with Cloudflare to serve the Pwned Passwords API at scale, meaning the service is highly available and performant even for production applications with significant query volumes.

The Bottom Line

Have I Been Pwned's implementation of k-anonymity is one of the most elegant solutions in modern applied security. It threads the needle between utility and privacy — giving you genuinely actionable breach intelligence without requiring you to hand over your most sensitive credentials to do it. Whether you're an individual Australian checking your personal accounts, a developer building a more secure application, or an IT manager trying to meet your obligations under Australian privacy law, HIBP's Pwned Passwords API is a tool worth understanding and using.

The next time someone asks whether it's safe to check your password on HIBP, you can explain exactly why it is — and why k-anonymity makes all the difference.