Oct 16, 2026, 8:03 PM@Viss I learned a lot about K-anonymity in just a few toots a while back. I think it was from @tychotithonus but I could be mistaken. If it was, I'd be curious about their take on it. I only really understand the basics of crypto in general.
An essential problem with HIBP "k-anonymity" (not actually what HIBP is doing) is that HIBP also returns the frequency of the submission hits.
Guess which password this probably was?
https://gist.github.com/roycewilliams/2034c9253d46fbcaefb13f8e5d42daa2
Answer:
https://gist.github.com/roycewilliams/2bb471cc90cce7f6834204344590fcac
Mitigation is for the password to be long and truly random (so it will always fall to the bottom of any such frequency-sorted list). But a naive human-generated password is a sitting duck.
Previous coverage here:
https://infosec.exchange/@tychotithonus/114185977710675432
Oct 16, 2026, 11:42 PM@tychotithonus @cR0w @Viss
AFAIU, it shouldn't matter where on that list your password is, assuming the leaks HIBP is based on are public knowledge.
The client is sending 20 bits of the hash of your password to HIBP. If your password has so little entropy that this narrows it down enough to guess it in a reasonable number of attempts, then HIBP may as well return a 204 no content, and someone who saw the request has the same chance of pwning you.
1/
Oct 16, 2026, 11:45 PM@tychotithonus @cR0w @Viss
Now, if an average HIBP response has around 2^10 hashes, as has the one you sent, then yeah, your password matching any of them means it has low enough entropy that this is a problem.
So I see 2 cases in which it's OK to call HIBP in the first place:
1. during initial setup, and refuse to set the password if it matches any of the returned hashes
2. if the system has a rate-limit on failed login attempts, so you can change the pw before the attacker does 2^10 tries