You can download a database from haveibeenpwned of SHA-1s of all the passwords, which is the only way you should be checking user passwords against an external database. It's also a good way!

Downloading the database is best, but you can also safely use their range API [1]. This can be run either client-side or server-side.

I built a toy webpage using the API [2], and you can see how straightforward the API is to use by checking the script [3].

[1] https://haveibeenpwned.com/API/v2#SearchingPwnedPasswordsByR...

[2] https://safepasswordchecker.hashbase.io/

[3] https://safepasswordchecker.hashbase.io/script.js

From memory their system works by a using a partial-hash, minimising the leak of the password.

So for: * Password: trustno1 * Hash: 1234567890abcdefghij

You send to the api:

* Hash: 12345

And it returns all hashes it knows of that start with 12345 along with a count of how many times each hashed password has been breached.

You then compare that list to see if your full hash exists in there.

If it exists - it's been breached. If not - you're clear.

I don't think the comment you replied to was referring to checking a "current" password.

It's about checking a "new" password when an account is created, or the password changed.

Having said that - I don't see any issue with checking current passwords when the user logs in - you don't send the password to the remote service, so it can't leak that way.

Yeah I know - checking a new password is worse!

Turns out he's downloaded a hashed list and is checking against that. Which is fine.

The “regular” api works on a hash of the first handful of characters - in no scenario do you send the actual password to a remote service, so what is your concern?

The check is done locally against a hash. There's no risk of leaking the password.

Ok, that is fair. I thought you were skipping this rule from Troy Hunt (HIBP creator): "Do not send any password you actively use to a third-party service - even this one!"