6 ms·

On the side of your question, but HIBP's API is designed in such a way that you don't have to give them your password to get notified if it has been hacked. You

On the side of your question, but HIBP's API is designed in such a way that you don't have to give them your password to get notified if it has been hacked. You instead provide HIBP with parts of the hash, and then it answers if you maybe have been compromised. Take a look at requests with devtools on the page https://haveibeenpwned.com/Passwords https://haveibeenpwned.com/Passwords So here it's taken one step further, you don't have to trust that it's the same code running on HIBP, because you don't have to trust them at all for the service to work.

faebi 6y ago
But how many people will check in detail what‘s submitted? And again, how do you prevent that different users get different functionality?
- prepend 6y ago
  Only a few need to check to see what’s submitted and serve as a canary for others. It’s possible some bad actor could do dumb stuff, but SSL helps in that at least the server would have a unique id. Personally the first time I used HIBP I checked the javascript that was running and read about what happened. It’s possible that someone could hack their server and replace the javascript with new bad versions. I don’t check anymore. But it’s unlikely, and a shared, common risk of using any site, I think. But the important thing with HIBP (and other sites) is that I never send them any sensitive information.
  - jhardy54 6y ago
    > Only a few need to check to see what’s submitted and serve as a canary for others. I couldn't agree more. Even if you have root on their server and do a full audit, there's nothing to stop them from changing the code the moment you log out.
- mcherm 6y ago
  > But how many people will check in detail what‘s submitted? That's a valid criticism. It only takes one person finding clear evidence of problematic behavior to advertise that fact to the entire community. So long as a small fraction of people do actually check, the whole community will be fine. But if only a negligible number of people check it, then perhaps no one will be checking when it is abused. > And again, how do you prevent that different users get different functionality? Well, it depends on how the system is discriminating among users. To a great extent, that kind of abuse is prevented by anonymous users. You don't have to log into HIBP in order to use it. The system could still be discriminating by IP address, or even by various kinds of browser fingerprinting (including just collecting the advertising company cookies that so effectively eliminate anonymity for much of the web). Occasionally using TOR won't help against this -- a malicious operator could simply provide "clean" functionality to all TOR users. - - - - On the whole, things like, k-anonymous API design, making source code open, or having a small fraction of users checking for security issues all help a great deal and make it difficult for a malicious operator to abuse the system. But none of them are perfect. In the end it comes down to trust. Troy Hunt has EARNED that trust due to his openness, and in no small part by choosing to implement protections like these that he didn't need to implement, and I find that extremely persuasive. If you take steps to ensure that your CANNOT cheat your "customers", then that's pretty good evidence you aren't likely to be trying to cheat them.
  - kungato 6y ago
    How do we know if anyone is checking?
    - joshspankit 6y ago
      Another good question but since it’s trivial (opening the browser dev tools during a submission), we can assume a significant number. Doubly so because any service that says it’s secure gets a lot more scrutiny.
- jhardy54 6y ago
  You can't verify. Even if you could, you can't ensure that the code will be replaced the moment you turn around. I investigated this thoroughly a few years ago, and the solution I came to is distributed computing. Join a peer-to-peer network an run the code directly on your own hardware or depend on someone that you actually trust. As far as I can tell there are no shortcuts that allow you to trust strangers with sensitive data.
chrisshroba 6y ago
This seems like it would still leave a vulnerability: There are many passwords that are commonly used, e.g. "password". If I submit "password" to haveibeenpwned, it hashes and sends the range "5BAA6". It seems to me that now anyone in control of haveibeenpwned could reasonably guess that my password has a decent chance of being "password". Using this methodology for the top 100 or 1000 passwords would presumably uncover a lot of passwords.
- snailmailman 6y ago
  HIBP (or an eavesdropping attacker) can’t really assume that your password is in the list. There’s an essentially infinite number of passwords that would result in a hash ending with 5BAA6. “password” may be the most likely if it was in the list, but surely attackers would have been guessing commonly used passwords either way. If your password is in the list, you should probably be changing. It being bad is how it ended up in the list.
  - chrisshroba 6y ago
    >>> HIBP (or an eavesdropping attacker) can’t really assume that your password is in the list. According to [1] by Troy Hunt, around 86% of passwords from one dump were already in the HIBP database, so attackers could assume your password is in the list with 86% certainty, extrapolating from that. If we look at the returned data for a sample hash prefix (that of "password", which is 5BAA6), and sort them by count of password use, we get these password hashes with the most usages: ~ curl -s 'https://api.pwnedpasswords.com/range/5BAA6' | sort -t: -k2 -n | tail 42BAADCD710F9EA7E62B60E01D05469AC64:14 EA2008F79BE2B0E0C02A1642725433BBB2F:15 3A8ADE4CF1DAD5342AF2F9FC9247EC21943:18 5E2BCB2FEF09257B0306B4744418999611B:18 A516C42C8CD4C7E7E328ABB90D002A9890E:29 CF2F87E596758D031C0006D1827C9908E5C:34 EF0E14CCB17E525D76050283148A57828F8:44 8E0D5C9D144BACC76E52C44F5B61E8DF629:213 2648FB0B2EDA4FDFF99BF51E912CD95C023:7201 1E4C9B93F3F0682250B6CF8331B7EE68FD8:3759315 Summing the counts gives 3768295, so 3759315/3768295= about 99.7% of passwords with that hash are "password". Going with a more obscure password, like say "obscure", you get 1801/4319 = about 42% of passwords being "obscure". This means that if I search for the password "obscure" on HIBP, HIBP can be about 40% sure that my password is "obscure". How is this not a huge security issue? I would agree that folks with unique passwords not appearing the database are safe, but anyone using a common password can be identified with pretty high probability, and even someone with a password only occurring once in the database is at risk because a typical query returns about 500 results: low enough that a human could brute force a web input that didn't have rate limiting in an hour or two. [1]: https://www.troyhunt.com/86-of-passwords-are-terrible-and-other-statistics/ https://www.troyhunt.com/86-of-passwords-are-terrible-and-ot...

faebi 6y ago

But how many people will check in detail what‘s submitted? And again, how do you prevent that different users get different functionality?

prepend 6y ago
Only a few need to check to see what’s submitted and serve as a canary for others. It’s possible some bad actor could do dumb stuff, but SSL helps in that at least the server would have a unique id. Personally the first time I used HIBP I checked the javascript that was running and read about what happened. It’s possible that someone could hack their server and replace the javascript with new bad versions. I don’t check anymore. But it’s unlikely, and a shared, common risk of using any site, I think. But the important thing with HIBP (and other sites) is that I never send them any sensitive information.
- jhardy54 6y ago
  > Only a few need to check to see what’s submitted and serve as a canary for others. I couldn't agree more. Even if you have root on their server and do a full audit, there's nothing to stop them from changing the code the moment you log out.
mcherm 6y ago
> But how many people will check in detail what‘s submitted? That's a valid criticism. It only takes one person finding clear evidence of problematic behavior to advertise that fact to the entire community. So long as a small fraction of people do actually check, the whole community will be fine. But if only a negligible number of people check it, then perhaps no one will be checking when it is abused. > And again, how do you prevent that different users get different functionality? Well, it depends on how the system is discriminating among users. To a great extent, that kind of abuse is prevented by anonymous users. You don't have to log into HIBP in order to use it. The system could still be discriminating by IP address, or even by various kinds of browser fingerprinting (including just collecting the advertising company cookies that so effectively eliminate anonymity for much of the web). Occasionally using TOR won't help against this -- a malicious operator could simply provide "clean" functionality to all TOR users. - - - - On the whole, things like, k-anonymous API design, making source code open, or having a small fraction of users checking for security issues all help a great deal and make it difficult for a malicious operator to abuse the system. But none of them are perfect. In the end it comes down to trust. Troy Hunt has EARNED that trust due to his openness, and in no small part by choosing to implement protections like these that he didn't need to implement, and I find that extremely persuasive. If you take steps to ensure that your CANNOT cheat your "customers", then that's pretty good evidence you aren't likely to be trying to cheat them.
- kungato 6y ago
  How do we know if anyone is checking?
  - joshspankit 6y ago
    Another good question but since it’s trivial (opening the browser dev tools during a submission), we can assume a significant number. Doubly so because any service that says it’s secure gets a lot more scrutiny.
jhardy54 6y ago
You can't verify. Even if you could, you can't ensure that the code will be replaced the moment you turn around. I investigated this thoroughly a few years ago, and the solution I came to is distributed computing. Join a peer-to-peer network an run the code directly on your own hardware or depend on someone that you actually trust. As far as I can tell there are no shortcuts that allow you to trust strangers with sensitive data.

chrisshroba 6y ago

This seems like it would still leave a vulnerability: There are many passwords that are commonly used, e.g. "password". If I submit "password" to haveibeenpwned, it hashes and sends the range "5BAA6". It seems to me that now anyone in control of haveibeenpwned could reasonably guess that my password has a decent chance of being "password". Using this methodology for the top 100 or 1000 passwords would presumably uncover a lot of passwords.

snailmailman 6y ago
HIBP (or an eavesdropping attacker) can’t really assume that your password is in the list. There’s an essentially infinite number of passwords that would result in a hash ending with 5BAA6. “password” may be the most likely if it was in the list, but surely attackers would have been guessing commonly used passwords either way. If your password is in the list, you should probably be changing. It being bad is how it ended up in the list.
- chrisshroba 6y ago
  >>> HIBP (or an eavesdropping attacker) can’t really assume that your password is in the list. According to [1] by Troy Hunt, around 86% of passwords from one dump were already in the HIBP database, so attackers could assume your password is in the list with 86% certainty, extrapolating from that. If we look at the returned data for a sample hash prefix (that of "password", which is 5BAA6), and sort them by count of password use, we get these password hashes with the most usages: ~ curl -s 'https://api.pwnedpasswords.com/range/5BAA6' | sort -t: -k2 -n | tail 42BAADCD710F9EA7E62B60E01D05469AC64:14 EA2008F79BE2B0E0C02A1642725433BBB2F:15 3A8ADE4CF1DAD5342AF2F9FC9247EC21943:18 5E2BCB2FEF09257B0306B4744418999611B:18 A516C42C8CD4C7E7E328ABB90D002A9890E:29 CF2F87E596758D031C0006D1827C9908E5C:34 EF0E14CCB17E525D76050283148A57828F8:44 8E0D5C9D144BACC76E52C44F5B61E8DF629:213 2648FB0B2EDA4FDFF99BF51E912CD95C023:7201 1E4C9B93F3F0682250B6CF8331B7EE68FD8:3759315 Summing the counts gives 3768295, so 3759315/3768295= about 99.7% of passwords with that hash are "password". Going with a more obscure password, like say "obscure", you get 1801/4319 = about 42% of passwords being "obscure". This means that if I search for the password "obscure" on HIBP, HIBP can be about 40% sure that my password is "obscure". How is this not a huge security issue? I would agree that folks with unique passwords not appearing the database are safe, but anyone using a common password can be identified with pretty high probability, and even someone with a password only occurring once in the database is at risk because a typical query returns about 500 results: low enough that a human could brute force a web input that didn't have rate limiting in an hour or two. [1]: https://www.troyhunt.com/86-of-passwords-are-terrible-and-other-statistics/ https://www.troyhunt.com/86-of-passwords-are-terrible-and-ot...