If I was him I'd do the same. HIBP is a side project of his and I wouldn't be able to sleep at night knowing I have the responsibility of securing billions of email & password combinations.
At the risk of the breach of those accounts adding fuel to the credential stuffing fire and reducing his overall credibility when providing security advice which is his primary occupation.
Too risky.
I know one of the weak password I stupidly reuse everywhere was compromised since I had someone buy something with my paypal account. But it comes up as clean in the password search. So it was probably cracked from one of the leaked hashes but the plain text was never entered into the public dumps.
Knowing that - for sure - a password has appeared in a breach is very useful.
It can only check against a database of known password leaks.
If you're as paranoid as you should be about then you can use an API to search using k-anonymity: https://api.pwnedpasswords.com/range/{hashPrefix} There you can replace "{hashPrefix}" with the first 5 characters of the SHA-1 of your password. It will return a list of all SHA-1's that start with the given 5 character prefix, as well as how many times they've been 'busted'. Ideally it will not return the full SHA of the password you're testing, meaning you're in the clear.
For testing purposes, the SHA-1 of "Passw0rd" is "21BD12DC183F740EE76F27B78EB39C8AD972A757".
---------
Edit : I previously stated you could search directly by the SHA-1 of your pass alone (in the regular web interface). It looks like this feature has been removed since he's added the k-anonymity feature. So your options are searching directly by password, or using the k-anonymity hash prefix API.
https://gist.github.com/schmich/aeaffac922271a11b70e9a79a5fe...
You need to look at the request being generated. Here's how to do it:
1) The SHA-1 of P@ssw0rd is 21BD12DC183F740EE76F27B78EB39C8AD972A757: https://passwordsgenerator.net/sha1-hash-generator/
2) Pass the first 5 chars to the API here: https://api.pwnedpasswords.com/range/21BD1
3) Find the suffix in the response and it has the count next to it: 2DC183F740EE76F27B78EB39C8AD972A757:51259
[0]: https://www.troyhunt.com/the-773-million-record-collection-1...
Oh no — pwned! This password has been seen 3,645,804 times before
They do have an API that allows you to search for your password based on a truncated checksum, so you can find out if your password was leaked, without revealing the password.
https://www.troyhunt.com/ive-just-launched-pwned-passwords-v...
Which does upload your password, which I think is an unacceptable risk.
But it also pulls untrusted code/CSS from various sites over HTTP. It's far from unclear who controls that code.
For instance this wall of code: http://az416426.vo.msecnd.net/scripts/a/ai.0.js
A more sane approach would be to just put your passwords in a file, maybe by export from your database manager. Take a sha1 of each password, then submit those. That way you aren't trusting any random 3rd party sites to run safe code.
If it’s ‘far from unclear’, it would seem to imply things are rather clear, IMHO.
far from unclear unclear clear far from unclear
^ ^
| |
-------------------------------------------------It would take substantial time, expertise, and effort to audit that single web page. Even then any of the numerous pieces could change at any time.
So the risk is high, especially for something you are putting trusted passwords into.
It sends the first N characters of the SHA1 hash of the password you provided to the server, the server replies with all the hashes it knows with that prefix, and then the client-side JS compares it to the rest of the hash it has.
If you don't believe me, you can look at the request said site issues for some arbitrary string - it's just the first 5 characters of the SHA1 hash, and the response from the server is as I (and that link) describe.
[1] - https://www.troyhunt.com/ive-just-launched-pwned-passwords-v...
There's some code that page uses: http://az416426.vo.msecnd.net/scripts/a/ai.0.js
Note the lack of https.
You are going to trust a page with that code with your important passwords?
Sure it claims to anonymize it first, but most don't know enough code to verify it themselves.
Much like trusting curl https://whatever.com | sudo /bin/bash
Crazy.
sha1=$(echo -n 'happy123' | tr -d '\n' | openssl sha1)
result=$(curl https://api.pwnedpasswords.com/range/${sha1:0:5}
2>/dev/null | grep $(echo ${sha1:5:35} | tr '[:lower:]' '[:upper:]'))
echo "Count: ${result#*:}"
No, I don't have any particular reason to trust it.
I was just pointing out that the claim you made was inaccurate.
Troy seems to have a fine reputation, but I don't want to trust the crown jewels (my passwords to everything) on Troy's reputation, the security of his site, cloudflare, and random javascript bits hosted in various places.
So sure the design and explanation of the page is that passwords are not uploaded. But since I can't practically verify that myself, I wouldn't upload passwords there. What's worse is even if I could audit every line of code, I couldn't guarantee other people wouldn't get a malicious version of the site.
So generally saying "Sure, type your password into a form on this webpage, I found an explanation that says it's not uploading it." is a very bad idea.
There's similarly plausible pages for things like generating SSL certs (not just CSRs), ssh keys, generating passwords for you, and similar that often have reassuring explanations that their security is just fine.
So generally never put your private key or plaintext password where a random 3rd party might read it. The promise that some anonymization process will be applied should not be enough to get you to risk it.
This reminds me of: http://bash.org/?244321
I claimed your initial unqualified statement, that it uploaded your password, was inaccurate, with both an explanation of what it was doing and the claim that I had not seen any evidence of it doing anything else.
I did not claim the site was not vulnerable to MITM or other injection attacks.
I did not claim you should trust this or any other resource with your password or any other data.
Of course, if we don't completely trust Troy Hunt and everybody associated with the site then we could assume that now those passwords have been added to a secret list of known unknowns, to use when trying to crack the hashed files they already have stored.
Security sure is difficult! I know it says at the top of the article that it is pitched at non-technical people but most of the people I know would have glazed over in the first few paragraphs..
Please don't make false assertions about what I was suggesting without any evidence.
Pwned Passwords consists of a number of tools, which one you choose to use depends on the concerns you have and the effort you choose to put in. Both the API and the SHA download files provide secure means of checking if your password is present in this data dump.
I would certainly not put any live passwords into the webform.
You could have made your points in a much more constructive and concise manner:
Pwned Passwords is a great data set, I would recommend against using the webform to check your password, instead download the hash file or utilize the extremely simple api. The webform is insecure because...
I mean I do, and that's why I have 100+ passwords that MIGHT be compromised. I don't even know where to start? Seems like the password should be shareable if you control the email or something like that. Fuck, I'd take a cc style last four type redaction or something.
I know because every time I register for a site I use [email protected] as my email.
You can also do that with gmail by using the [email protected] syntax but it's well known and trivial for a hacker to defeat.
Even if it's not in the HIBP base, you should always assume that. That's why you should always enable MFA everywhere it's possible and consider all services where it's not already compromised.
But as he discusses in the post, that leaves users knowing that their email address was in the data dump, but with no way of knowing which site it came from, or what password was breached.
So while this increases the number of records in HIBP, and perhaps makes the password popularity tracker a bit more comprehensive, it still leaves users exposed.
I know which password of yours was breached, and that information is now effectively public, but you probably don’t know where to find it yourself, and I won’t tell you which one it was. So I guess just assume all your passwords are cracked and use a password manager.
I don’t really hold it against Troy, because again, I respect his decision not to store plains directly associated with usernames. He did as much as he was willing to with the data, and it’s better than nothing, but not great all the same.