You don't send the password to him. Your browser hashes it, then sends the first few characters of the hash to the API. You can look at the network panel of you don't believe it. The protocol is fully documented on the site. I used it to make a React hook to check your user's password when they sign up. https://github.com/ascorbic/use-pwned-passwords

Thanks for the comment. It’s enough of the hash shared for me to be uncomfortable and for me to recommend not using it.

I applaud them for limiting the risk. But when the information shared with them let’s a bad guy know the 500 possible matches out of trillions, that’s not good.

It’s not literally clear text, which is nice. But it’s not without risk. And it’s not a good practice to share portions of password hashes with untrusted parties. Like a friendly hacker who runs a nonprofit site or whatever company buys it.

What you do with your own data is your decision, but if these details are enough for you to _recommend_ that other people not use it, then your advice needs to come with an "I ignore math in favor of uninformed prejudice" disclaimer, because you're making things worse with your security mysticism.

That wouldn’t be a disclaimer that is accurate, so I don’t think I would use it.

Anyone who takes my security recommendations is already familiar enough of my math vs informed prejudices balance.

Keep in mind that your password may not be contained in the result set from HIBP (and if it is, you should likely change it anyway). So the attack space is only reduced to "any string whose hash begins with these characters", which should be considerably larger than 500 or however many results HIBP returns. It would be drastically smaller only if the attacker knew the hash was contained in HIBP.

Effectively, since HIBP asks for 5 characters of the hash, the space is the same as if the full hash were 5 characters shorter.

This is a good point as not all passwords will be in known set.

I guess it’s only a 1:500 if the password has been pwned. In which case, the owner should promptly change it and remove the risk.

Thanks, I didn’t think of that. For some reason I was stuck in thinking that all passwords have been pwned and in the file.

Why? I would be concerned only with the full hash (because people tend to use the same few passwords across many places), but given it's a partial hash, there's literally no info being sent around.

> The idea of sending your passwords to a third party is pretty crazy.

Thats not how it works. You hash your password first and then take the first 6 chars of the hash to query the api. The api then returns all of the hashes that begin with those 6 chars and you scan the results for your full hash.

https://blog.cloudflare.com/validating-leaked-passwords-with...

That is not a sound security policy. Reducing the attack range of my password from 1:72^8 (or greater with non alpha, more than 8 chars) to 1:500 is only a matter of time before I’m pwned. Should anyone ever want to pwn me (which I hope they don’t).

It only reduces the odds to such a tiny number if your password is in the list (otherwise, guessing the remaining 136 bits of the hash is infeasible). If that's the case, however, sending a part of the hash to the server is still the best idea, because you want to know that the password needs to be changed immediately. At this point, the 72^8 estimate no longer matters, both because the full list of HIBP passwords is much smaller than that and because you don't know if other information (such as the corresponding username) was leaked along with the password.

Apparently most of the SHA1 hashes of haveibeenpwned passwords were cracked about a year ago:

https://blog.cynosureprime.com/2017/08/320-million-hashes-ex...

I wonder if segments of the list are around to create a password-blacklist

edit: previous discussion https://news.ycombinator.com/item?id=16799826

Sure, the source they're referencing, with a plaintext torrent, is here: https://hashes.org/leaks.php?id=515 which was last updated yesterday.

However, this shouldn't be alarming.

1) Attackers already have the plaintext password of these hashes. That's why they're in HIBP's repository in the first place.

2) You should already assume most sites/apps don't have proper security hygiene. Password re-use is what will get you. If you wish to warn your users if they're reusing a password, then HIBP's API should already do well for that.

3) You have truly astronomical odds of generating the same password as one in a leaked database should yours contain enough bits of entropy. Remember that GPU's are making millions of guesses per second in the first place when cracking passwords, and significantly slower if the hashing algorithm protects against GPU attacks.

How sensitive are most of these passwords really though? What is a big company or Google going to do? Log into all your accounts and steal your data? That doesn't sound like a very realistic scenario or even a threat model you should be worried about.

Even less so with the strategy of just sending a small hashed part of the password to HIBP like others already explained.

Wait, WHAT?

Troy’s site asks you to send passwords? Not just login identifiers like an email or username?

In that case, you should AT LEAST be sending a hash of a password, a very key-strengthened hash (like sha2 done 1000 times) and on his side Troy can see if it matches anything.

Yeah, that's what HIBP does. See here: https://www.troyhunt.com/ive-just-launched-pwned-passwords-v...

I really feel Troy has handled HIBP very, very carefully, honestly, and with the utmost transparency so far. He seems to have put in a lot of thought into everything - whether it is rolling out a feature or planning the future of HIBP.

To clarify for the GP: HIBP sends the first handful of characters of the password hash to the server, not the password itself or even the full hash. The server then returns all of the hashes matching that prefix, and the remainder of the comparison is done client side.