What Is k-Anonymity for Breach Checks?
Checking whether a password showed up in a data breach is useful — but sending that password to a random website is a terrible idea. k-Anonymity is the privacy pattern that makes “have I been pwned?” style checks safe enough to use in the browser.
The problem with naïve breach lookups
A naïve API would accept your password and return “found” or “not found.” That means the service (or anyone on the path) sees the secret. Even HTTPS does not erase the trust problem: you handed your password to someone else’s server.
Password managers and tools needed a better model.
How k-anonymity works for password checks
Have I Been Pwned (HIBP) popularized a range API:
- Your browser hashes the password with SHA-1 (for compatibility with HIBP’s corpus).
- Only the first 5 characters of the hash (the prefix) are sent to the API.
- The API returns every hash suffix in that bucket — often hundreds or thousands of candidates.
- Your browser compares the full hash locally and tells you if there is a match.
The server never receives the complete hash or the password. It only learns which prefix bucket you queried. That is the k-anonymity idea: you are indistinguishable among the many passwords that share the same prefix.
Why this matters for PassTip
PassTip’s breach check runs in your browser and talks to HIBP’s range API using that pattern. The generated or typed password is not uploaded in cleartext, and PassTip does not store it.
Try it here:
What k-anonymity does not promise
- It does not make a weak password strong.
- It does not mean the password was never stolen — only that it is not in the indexed corpus (or not under that exact string).
- It does not protect you if you paste secrets into untrusted pages that do not use this pattern.
Always verify that a tool documents range / prefix hashing before you trust a “breach check.”
SHA-1 and password hashing confusion
HIBP stores password appearance hashes for lookup, not recommended storage hashes for your own apps. Modern authentication systems should use Argon2 or similar for storing user passwords. SHA-1 here is a historical lookup format, not a recommendation for how to salt and store credentials in a product database.
For vocabulary, see also:
When to run a breach check
- After generating a new password you plan to reuse from muscle memory (better: do not reuse).
- When migrating old accounts you created years ago.
- Before you “keep” a password that feels familiar — familiarity is often a warning sign.
If the check hits, generate something new and unique:
Bulk hygiene
If you are rotating many accounts, generate unique secrets in bulk, then check any candidates you did not freshly generate:
Bottom line
k-Anonymity turns “send my password to check it” into “send a tiny hash prefix and finish the check offline.” That is the right privacy default for breach lookups — and it is how PassTip approaches the problem.