7 ms·

Firefox is using the wonderful haveibeenpwned resource. There is also a public API for haveibeenpwned if you want to incorporate it into your own clients: http

Firefox is using the wonderful haveibeenpwned resource. There is also a public API for haveibeenpwned if you want to incorporate it into your own clients: https://haveibeenpwned.com/API/v2 https://haveibeenpwned.com/API/v2 Please note rate limits/ abuse policy so everyone can use: https://haveibeenpwned.com/API/v2#RateLimiting https://haveibeenpwned.com/API/v2#RateLimiting (I am not affiliated)

jakejarvis 7y ago
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-1password/ https://blog.1password.com/finding-pwned-passwords-with-1pas... [1] https://www.troyhunt.com/ive-just-launched-pwned-passwords-version-2/ https://www.troyhunt.com/ive-just-launched-pwned-passwords-v...
- waynesonfire 7y ago
  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 https://app-updates.agilebits.com/product_history/B5X [1] https://support.1password.com/kb/201907/ https://support.1password.com/kb/201907/
  - groovecoder 7y ago
    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 https://haveibeenpwned.com/api/v2/breaches [2] https://wiki.mozilla.org/Firefox/RemoteSettings https://wiki.mozilla.org/Firefox/RemoteSettings [3] https://hg.mozilla.org/mozilla-central/file/6484c07ff83649914781ddc9cfb70e98466cdd7a/browser/components/aboutlogins/AboutLoginsParent.jsm#l377 https://hg.mozilla.org/mozilla-central/file/6484c07ff8364991...
    - MrStonedOne 7y ago
      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."
  - MrStonedOne 7y ago
    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.
Deimorz 7y ago
Probably worth noting that Have I Been Pwned is now up for sale: https://www.troyhunt.com/project-svalbard-the-future-of-have-i-been-pwned/ 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.
- denzil_correa 7y ago
  > 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.
  - NeutronStar 7y ago
    Sure, but until then, nope.
  - bradknowles 7y ago
    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.
- Mirioron 7y ago
  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.
  - 7y ago
euroclydon 7y ago
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.
- tomschlick 7y ago
  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.
  - deleted 7y ago
    [deleted]
- bradknowles 7y ago
  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.
cablej 7y ago
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/ 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.

jakejarvis 7y ago

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-1password/ https://blog.1password.com/finding-pwned-passwords-with-1pas... [1] https://www.troyhunt.com/ive-just-launched-pwned-passwords-version-2/ https://www.troyhunt.com/ive-just-launched-pwned-passwords-v...

waynesonfire 7y ago
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 https://app-updates.agilebits.com/product_history/B5X [1] https://support.1password.com/kb/201907/ https://support.1password.com/kb/201907/
- groovecoder 7y ago
  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 https://haveibeenpwned.com/api/v2/breaches [2] https://wiki.mozilla.org/Firefox/RemoteSettings https://wiki.mozilla.org/Firefox/RemoteSettings [3] https://hg.mozilla.org/mozilla-central/file/6484c07ff83649914781ddc9cfb70e98466cdd7a/browser/components/aboutlogins/AboutLoginsParent.jsm#l377 https://hg.mozilla.org/mozilla-central/file/6484c07ff8364991...
  - MrStonedOne 7y ago
    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."
- MrStonedOne 7y ago
  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.

Deimorz 7y ago

Probably worth noting that Have I Been Pwned is now up for sale: https://www.troyhunt.com/project-svalbard-the-future-of-have-i-been-pwned/ 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.

denzil_correa 7y ago
> 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.
- NeutronStar 7y ago
  Sure, but until then, nope.
- bradknowles 7y ago
  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.
Mirioron 7y ago
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.
- 7y ago

euroclydon 7y ago

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.

tomschlick 7y ago
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.
- deleted 7y ago
  [deleted]
bradknowles 7y ago
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.

cablej 7y ago

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/ 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.