4 ms·
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
by 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...
- 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 agoEven 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 agoYes, 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 agoWait, 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.