I always thought that it could be reasonably simple to have a safe alternative. Have people enter a SHA256 of their password instead, and match against a database of other hashes.
Almost everyone interested in checking for password leaks knows how to generate SHA256 of a string. And those who don't shouldn't put their passwords on the internet.
Or even better, generate hash for all passwords in the database, package these hashes together with a simple search script and let people download it. That way, you are not sending any information anywhere, and noone can exploit the passwords, because hash is a one way function.
Then again, that download could be really large. I admit I have no idea how much storage would that take. But it's just text, so easily compressible. And with some smart indexing, it should be possible to keep most compressed and only unpack a relatively small portion to find a complete match.
Then again, I have virtually no background in cryptography, could be something horribly wrong with this.
When you do a check on https://haveibeenpwned.com/Passwords nothing is sent to the server. Instead the password is hashed locally and a list of the hash range is downloaded, which contains all the hashes and the number of occurrences.
The server doesn't receive the password, neither in plain-text nor hash form.
It would be easy enough to add this as a "secret" feature:
* user submits password
* gets hashed client side
* server compares it against stored hashes
* server also re-hashes the stored hash, and compares it against the hash received from the client
This would effectively mean that either entering the password, or the password hash would correctly match, since when entering the hash you are effectively "double" hashing the password which gets compared to the double hashed password on the server.
The upside is that users who don't understand hashing or don't feel like opening a sha256 tool wouldn't have to change their behavior or even be confused by a dialog explaining why they should hash the input, while advanced users could find out about the feature via another channel (e.g. hackernews).
The downside would be that it adds an extra hash step to every comparison on the sever. It's hard to know how expensive this would be for them.
Care to explain how you can tell what scripts gp was sent for the page https://haveibeenpwned.com/Passwords and what scripts he will be sent on future visits?
Almost everyone interested in checking for password leaks knows how to generate SHA256 of a string. And those who don't shouldn't put their passwords on the internet.
Or even better, generate hash for all passwords in the database, package these hashes together with a simple search script and let people download it. That way, you are not sending any information anywhere, and noone can exploit the passwords, because hash is a one way function.
Then again, that download could be really large. I admit I have no idea how much storage would that take. But it's just text, so easily compressible. And with some smart indexing, it should be possible to keep most compressed and only unpack a relatively small portion to find a complete match.
Then again, I have virtually no background in cryptography, could be something horribly wrong with this.