Probably worth noting that Have I Been Pwned is now up for sale: https://www.troyhunt.com/project-svalbard-the-future-of-have...

I've always been a huge fan of the project (and Troy) and understand that it's gotten to a point where he can't keep running it as a spare-time project, but I'm still not very happy about seeing it being shopped around. I can't see how this type of service needing to find a way to become a business will be a good thing overall, especially when it keeps getting integrated into other programs and services like this. Troy pledges that nothing will change, but every company getting acquired does that, and then things change anyway.

The best result would probably be something like Mozilla buying it and/or paying Troy to just keep doing what he's doing.

> The best result would probably be something like Mozilla buying it and/or paying Troy to just keep doing what he's doing.

Mozilla could very well be one of the potential candidates for HIBP ownership.

Troy has spoken about that.

They are a known candidate, but they fall further down the list on some of his criteria than he would like. However, he doesn't provide any further details on this issue.

Meanwhile, he continues to look for other candidates.

This is why I never check passwords against haveibeenpwned. The idea of sending your passwords to a third party is pretty crazy. Even when I knew the owner and trusted him, there’s no way I’d know everyone with access. And now the site could be sold to someone like Google and God knows what they would do with all that traffic.

I used to download the whole file and check locally, but it’s too much of a pain to do consistently.

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.

I would even say that a project like this should be run by the government(s). I get that foreign politics would wreck havoc there, but governments have to deal with data breaches anyway.

The government seems like the party most likely to, and most able to, abuse being in control of a trusted security resource. Would you trust the API if it was operated by the USA (NSA), Russia, China, Australia, or the UK?

I was a fan of the project. But when it went up for sale, I contacted him to ask for my details to be removed from his db (re the auto-notification stuff), and didn't get any response.

I'm no longer a fan.

Guess I shouldn't have trusted him with my personal information.

1Password uses the HIBP API too [0] which has actually saved me a few times.

The mechanics behind the v2 API (using k-anonymity with hashes [1]) are pretty interesting too. Troy has clearly put a lot of thought and time into what started as a pet project a few years ago and should be infinitely commended!

[0] https://blog.1password.com/finding-pwned-passwords-with-1pas...

[1] https://www.troyhunt.com/ive-just-launched-pwned-passwords-v...

I just read through 1Password release notes [0], "Addressed a bug in the new popup where items were checked for vulnerable passwords even if you hadn't opted in to the Have I Been Pwned service." which also links to a KB article that talks about the security risks of HIBP [1]

I would be very concerned if my credentials are being shared in _any_ form with 3rd parties without my explicit permissions.

I hope this firefox feature is disabled by default.

[0] https://app-updates.agilebits.com/product_history/B5X [1] https://support.1password.com/kb/201907/

Disclaimer: I'm the Firefox sec engineer working on this feature.

Just to clear this up: The code for this is actually way simpler and sends no data to either Mozilla nor HIBP. To prevent Firefox from sending data update pings to HIBP, Firefox Monitor maintains a copy of publicly available HIBP breaches and their metadata [1] in the Firefox "Remote Settings" service. [2]

Using that data, Firefox simply checks for saved logins for breached sites where the saved password is older than the breach. [3]

[1] https://haveibeenpwned.com/api/v2/breaches [2] https://wiki.mozilla.org/Firefox/RemoteSettings [3] https://hg.mozilla.org/mozilla-central/file/6484c07ff8364991...

This explanation confused me, so let me rewrite it:

"Firefox downloads a list of breached domain names and the date they were breached, and merely checks if you have any stored logins on any breached domains that are older then the breach date."

Credentials are not shared under the hibp password system. the first five characters of the hex encoded md5 of the password is shared and the server responds with matching hashes. If 20 bits (2 and a half characters) of hashed entropy can compromise your password you have bigger problems.

There are fundamental privacy risks to using the HIBP Pwned Passwords service which should be considered when implementing it. See my writeup here — https://cablej.io/blog/k-anonymity/. In short, despite claims of protecting privacy, a malicious server can recover user passwords in some cases even if they haven’t previously been compromised.

One thing HIBP does is match a password against a list of half a billion leaked passwords without regard for the username portion of the credentials. They do it because of the NIST guidance to compare credentials to known data leaks. The same NIST who's previous guidance was a complicated password entropy algorithm, which they later dropped.

I've always questioned the logic making 500,000,000 passwords off limits when no connection is made to the username. Work-factor hashing algorithms, rate limiting account locking and 2FA are supposed to protect user from brute force attacks. I think they can handle an attack based on 500 million possibilities.

Now, if they matched the username/password pair, that would be great.

The thing is that all of the passwords in his database, are ones that the blackhats already know. As in, they not only have the hashes, but the full in-the-clear passwords. His sources for these lists are blackhats themselves, who happen to leak their copies of their password lists, one way or the other.

And all the major password cracking tools will typically try all the known bad passwords, before they try anything else. And they'll try all known likely variants, before making any potential brute-force attempts.

So, it doesn't matter if the password you want to use is on this list and you want to use it anyway, just because it has never been associated with your userid.

The simple fact that you're trying to use a known bad password that has ever been used before by anyone else, is enough to increase by many, many orders of magnitude the likelihood that someone will be able to crack your new favourite password.

Bad passwords are simply bad, regardless of who tries to use them. Some are worse than others, but they're all bad.

This aspect of HIBP helps you discover if any of your passwords have ever been cracked by anyone, and therefore now on the list of known bad passwords.

The results show how often it was breached so you could always just blacklist passwords leaked more then 100 times or so. The really dangerous ones are the "common" one word passwords used hundreds of thousands of times.