5 ms·

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

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

acqq 6y ago
> a typical query returns about 500 results If you personally want to check your password wouldn't it help to curl more queries? Probably also taking care to make not too much per some unit of time?
- chrisshroba 6y ago
  Even with 10 or 100 queries you still will get a probability distribution of (I'm guessing) 20-200 passwords that make up the most likely 50% of passwords, so I'm not sure how much good this would do if your password is relatively common. If it's very obscure this could help more, but you're still narrowing the password search space from 500M to 5k-50k.
  - acqq 6y ago
    Yes, if you suspect your password is common maybe you shouldn‘t use that service at all, but just download some smaller list of “common passwords.” I also see problematic that, if I understood correctly, some browsers query automatically that service with your passwords which browser collected whenever you “saved” some login. And they claim that is “for your security.”
jve 6y ago
Wait, if you query HIBP, you are actually asking: is it safe to use thus password? If you have a match, you will certanly use different password. And, by the way, they have username/hashes before you even use their API.
- chrisshroba 6y ago
  > Wait, if you query HIBP, you are actually asking: is it safe to use thus password? I agree - this is the main use of HIBP. > If you have a match, you will certanly use different password. I doubt this is true in all cases. Sometimes people get lazy. But nonetheless, a malicious actor could still capitalize on the few minutes between a user checking a password on HIBP and that user changing their password. For example: for every password lookup, pick the most likely password with that hash, and if it has at least 90% share of the passwords with that hash, try to correlate an email address to their IP address (using leaked dumps), and then try to log into gmail with those credentials. Even if it works 1% of the time, a lot of harm could be done in a few minutes. (For example, US Social Security Numbers may appear in a years-old employment document in the email). > And, by the way, they have username/hashes before you even use their API. But they don't necessarily have yours. If I am somebody who uses a different password on every site, and I check a password for a site that has not had a leak, then they do not have an association between my email and my password before my query, and they do after my query. Regardless of the particulars of possible exploits, I'm mainly claiming that the original comment above (by @matsemann) is not true, in that some level of trust in HIBP is necessary to input a sensitive password.
  - gnabgib 6y ago
    This isn't really the way HIBP is used. While you can query the HIBP endpoint, the hashes are also available as (large) torrent downloads too. For many use-cases this means as the HIBP operator you won't see those requests since other service providers are likely using a local cache and not taxing Troy's infrastructure. Even when you are directly querying, the request is very likely proxied by the service operator so you won't be able to derive IPs specifically, just someone using Okta tried the password `obscure` (but not that they set their password to this - whomever they were, note I'm not saying Okta directly queries - just an example). Further, security recommendations (eg OWASP) require that companies test potential passwords against known leaks and discourage or prevent users from using frequently found values (typically 100+ uses or leaks.. note this either means one user has unluckily been leaked 100 times, or 100 people have used the same password) - this again encourages both proxied and possibly cached lookups (vs trusting client side code which could be disabled). Note that the expected use case is at password creation or password change, the new candidate is tested - not upon every login. Ok so many use cases are removed - maybe your locally running password manager allows you to test a potential new password against leaks. Now we have a rare example of what you're hypothesizing, at this point you're trying to tie an IPv4 address to an identity. Many networks have either shared IPv4 addresses (NAT/GNAT in major metros, corporations, public Wifi), or dynamic IPv4 addresses (change daily/weekly/monthly). It's pretty hard (though not impossible) to link an IP to a person.. and vice versa, between 3g, 4g, 5g, wifi, work, home, complementary, wired and wireless connections a single person may appear across several addresses. Finally the idea of accounts - knowing a specific IP just tested the password `password` and Aretha Franklin is most likely at that IP.. well, which of the hundreds of services might she be potentially considering the new password for? (again - testing, not setting the password to). If you could narrow it to one service, or brute force all of them, and assume the user ignores the dire warnings, you still need to know their user credential (be it email - of which they may have many, username - of which they may have many, or service-generated username which you'd need insider knowledge to obtain) If you're worried about trust of your sensitive password, your password manager and the service you're using it on (if you reuse passwords) need far more.

acqq 6y ago

> a typical query returns about 500 results If you personally want to check your password wouldn't it help to curl more queries? Probably also taking care to make not too much per some unit of time?

chrisshroba 6y ago
Even with 10 or 100 queries you still will get a probability distribution of (I'm guessing) 20-200 passwords that make up the most likely 50% of passwords, so I'm not sure how much good this would do if your password is relatively common. If it's very obscure this could help more, but you're still narrowing the password search space from 500M to 5k-50k.
- acqq 6y ago
  Yes, if you suspect your password is common maybe you shouldn‘t use that service at all, but just download some smaller list of “common passwords.” I also see problematic that, if I understood correctly, some browsers query automatically that service with your passwords which browser collected whenever you “saved” some login. And they claim that is “for your security.”

jve 6y ago

Wait, if you query HIBP, you are actually asking: is it safe to use thus password? If you have a match, you will certanly use different password. And, by the way, they have username/hashes before you even use their API.

chrisshroba 6y ago
> Wait, if you query HIBP, you are actually asking: is it safe to use thus password? I agree - this is the main use of HIBP. > If you have a match, you will certanly use different password. I doubt this is true in all cases. Sometimes people get lazy. But nonetheless, a malicious actor could still capitalize on the few minutes between a user checking a password on HIBP and that user changing their password. For example: for every password lookup, pick the most likely password with that hash, and if it has at least 90% share of the passwords with that hash, try to correlate an email address to their IP address (using leaked dumps), and then try to log into gmail with those credentials. Even if it works 1% of the time, a lot of harm could be done in a few minutes. (For example, US Social Security Numbers may appear in a years-old employment document in the email). > And, by the way, they have username/hashes before you even use their API. But they don't necessarily have yours. If I am somebody who uses a different password on every site, and I check a password for a site that has not had a leak, then they do not have an association between my email and my password before my query, and they do after my query. Regardless of the particulars of possible exploits, I'm mainly claiming that the original comment above (by @matsemann) is not true, in that some level of trust in HIBP is necessary to input a sensitive password.
- gnabgib 6y ago
  This isn't really the way HIBP is used. While you can query the HIBP endpoint, the hashes are also available as (large) torrent downloads too. For many use-cases this means as the HIBP operator you won't see those requests since other service providers are likely using a local cache and not taxing Troy's infrastructure. Even when you are directly querying, the request is very likely proxied by the service operator so you won't be able to derive IPs specifically, just someone using Okta tried the password `obscure` (but not that they set their password to this - whomever they were, note I'm not saying Okta directly queries - just an example). Further, security recommendations (eg OWASP) require that companies test potential passwords against known leaks and discourage or prevent users from using frequently found values (typically 100+ uses or leaks.. note this either means one user has unluckily been leaked 100 times, or 100 people have used the same password) - this again encourages both proxied and possibly cached lookups (vs trusting client side code which could be disabled). Note that the expected use case is at password creation or password change, the new candidate is tested - not upon every login. Ok so many use cases are removed - maybe your locally running password manager allows you to test a potential new password against leaks. Now we have a rare example of what you're hypothesizing, at this point you're trying to tie an IPv4 address to an identity. Many networks have either shared IPv4 addresses (NAT/GNAT in major metros, corporations, public Wifi), or dynamic IPv4 addresses (change daily/weekly/monthly). It's pretty hard (though not impossible) to link an IP to a person.. and vice versa, between 3g, 4g, 5g, wifi, work, home, complementary, wired and wireless connections a single person may appear across several addresses. Finally the idea of accounts - knowing a specific IP just tested the password `password` and Aretha Franklin is most likely at that IP.. well, which of the hundreds of services might she be potentially considering the new password for? (again - testing, not setting the password to). If you could narrow it to one service, or brute force all of them, and assume the user ignores the dire warnings, you still need to know their user credential (be it email - of which they may have many, username - of which they may have many, or service-generated username which you'd need insider knowledge to obtain) If you're worried about trust of your sensitive password, your password manager and the service you're using it on (if you reuse passwords) need far more.