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 :)
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.
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.