So I should check my passwords against some remote API I have no idea who controls to see if they've been compromised? Does this API always return true?
It sends the first 5 characters of the SHA-1 hash to the API, which seems reasonable. To be safe, you could check after rotating all your passwords, or I suppose you could download the raw data yourself to check directly.
And the API is controlled by Troy Hunt, not some rando.
Troy Hunt and people who work at Cloudflare. But yeah it depends on your threat model. If it's just a random website password than it's probably fine to check. If you're trying to keep secrets from the state then maybe not.
Regardless of your threat model, you can read the code and see how it works. It's short and easy to understand. It doesn't send anything more than the first 5 characters of the SHA1 hash.
Sure but that leaks some information about your password. SHA-1 hashes are significantly quicker to compute than a password hash (and rainbow tables exist making it even faster). So the first five characters can be used to narrow the search space.
This is however not likely a real problem unless your threat model includes targeted attacks.
If you're already using a password manager, shouldn't you be using different (random) passwords for every service anyway? What's the point then?
I guess it makes sense to use this if you've begun using a password manager without changing your old passwords. But if possible you should really be doing that instead.
Also, I still don't understand why Troy doesn't use a cryptographically secure hash function instead of SHA1.
Say I send the (truncated) hash of one of my passwords to his service and it returns no match in his database. I then consider it secure because it's supposedly not leaked. But shouldn't I really do consider it leaked because I've revealed an insecure hash of it to a third party?
What's there to lose with using a secure hash function over SHA1? Surely the one-time cost of hashing the database of passwords is negligible?
Just because you're using a password manager doesn't mean none of the services you have a password on has had a leak. In such case, you'd still want to change your password on that service.
I've done a livestream recently showing the implementation of a similar program in Nim. It's a pretty good first-time project for anyone to try in a programming language they are learning.
I tried it with the passwords "password", "test", "123", "12345" and it didn't report any of them as compromised, which they surely are.
EDIT: It's because it's including a trailing endline before hashing every password. This is a serious bug.
EDIT2: Latest version in the repo does work.
EDIT: Which you've now merged :)
https://github.com/justwatchcom/gopass/blob/master/docs/feat...
And the API is controlled by Troy Hunt, not some rando.
This is however not likely a real problem unless your threat model includes targeted attacks.
https://github.com/kevlar1818/is_my_password_pwned
I tried to incorporate Troy Hunt's advice based on the frequency of occurrences in the database.
I guess it makes sense to use this if you've begun using a password manager without changing your old passwords. But if possible you should really be doing that instead.
Also, I still don't understand why Troy doesn't use a cryptographically secure hash function instead of SHA1. Say I send the (truncated) hash of one of my passwords to his service and it returns no match in his database. I then consider it secure because it's supposedly not leaked. But shouldn't I really do consider it leaked because I've revealed an insecure hash of it to a third party? What's there to lose with using a secure hash function over SHA1? Surely the one-time cost of hashing the database of passwords is negligible?
Here is the video: https://youtu.be/Di2O_lIPxb4
In case anyone else likes ruby, someone posted a link to a ruby script that does similar checks the other day on HN.
https://gist.github.com/schmich/aeaffac922271a11b70e9a79a5fe...