You didn't explicitly ask about this, but it is very related to your question (and mentioned in the comments), so I thought I'd bring it up. In particular, some more details can give some clues on evaluating stuff like this.
haveibeenpwned also has a service that let's you look up to see if a given password has been leaked before. I could see this service being even more "questionable". After all, who wants to go around stuffing their password in a random website? You could even imagine a conversation with a skeptic:
- Self: If I type my password in here it will tell me if it has showed up in a hack before! This will help me know if it is safe!
- Skeptic: Yeah, but you have to give them your password
- Self: Maybe, but even if I don't trust them, if they don't also know my email then it isn't a big deal, and they don't ask for me email address
- Skeptic: Except that they also have a form that asks for your email. They probably use a cookie to associate your two requests and get your email and password together. If they are really sneaky they use non-cookie based methods of tracking so it's even harder to tell they are doing it!
- Self: Wait! It says here that they don't send off my password, just the first few characters of my password's hash. They definitely can't get my password from that!
- Skeptic Just because they say it doesn't mean its true. They probably do send off your password, associate it with your email (because you probably check your email in the same session), and then hack all your accounts.
Of course, we can't verify what happens after we send them our data. Your email address definitely gets sent over, and there are no promises that they aren't secretly turning that into a gigantic email list that gets used for the next wave of Nigerian Prince emails.
What about the password though, or the fact that the two requests might be connected? With modern browsers, it is very easy to verify that your password isn't actually sent to their server. This service is designed so that only the first 5 characters of the hash of the password are sent off. The service then returns the hashes of all known passwords that start with that prefix. Then, the client simply compares the full hash against the returned ones to see if there is a match. Neither the password nor even the hash of the password are even sent.
You can verify this by going to the password search page, opening up your developer tools, and looking at the network tab (chrome, firefox). Put in a password (not yours if you're still worried) and hit submit. If you do this for
password you'll see an HTTP request that hits
5BAA6 being the first 5 characters of the hash of
password). There are no cookies attached, and the actual submitted password never shows up in the request. It responds with a list of ~500 entries, including
1E4C9B93F3F0682250B6CF8331B7EE68FD8 which (at the moment) lists
3645804 matches - aka the password
password has showed up about 3.5 million times in separate password leaks. (the SHA1 hash of
With only that information the service has no way to know what your password is, or even if it shows up in their database. There are a near limitless variety of hashes that might come after those first 5 digits, so they can't even guess whether or not your password is in their database.
Again, we can't know for sure what happens to the data after it leaves our browser, but they have certainly put a lot of effort into making sure that you can check to see if your password has leaked without actually sending them your password.
In summary, Troy is definitely a respected member of the community, and there are aspects of this that we can verify. Certainly, there have never been any cases where trusted members of a community later break that trust :) I definitely use these services, although I don't know if you want to trust some random person on the internet. Then again, if you weren't willing to trust some random person on the internet, then why are you here?