6 ms·

I don't think checking against haveibeenpwned is a good idea. They recommend against checking your current password, and you're automatically checking every use

I don't think checking against haveibeenpwned is a good idea. They recommend against checking your current password, and you're automatically checking every users current password?

bscphil 7y ago
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!
- fwip 7y ago
  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#SearchingPwnedPasswordsByRange https://haveibeenpwned.com/API/v2#SearchingPwnedPasswordsByR... [2] https://safepasswordchecker.hashbase.io/ https://safepasswordchecker.hashbase.io/ [3] https://safepasswordchecker.hashbase.io/script.js https://safepasswordchecker.hashbase.io/script.js
LeoPanthera 7y ago
The check is done locally against a hash. There's no risk of leaking the password.
- tomglynch 7y ago
  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!"
lysp 7y ago
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.
stephenr 7y ago
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.
- tomglynch 7y ago
  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.
  - stephenr 7y ago
    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?

I don't think checking against haveibeenpwned is a good idea. They recommend against checking your current password, and you're automatically checking every users current password?

bscphil 7y ago

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!

fwip 7y ago
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#SearchingPwnedPasswordsByRange https://haveibeenpwned.com/API/v2#SearchingPwnedPasswordsByR... [2] https://safepasswordchecker.hashbase.io/ https://safepasswordchecker.hashbase.io/ [3] https://safepasswordchecker.hashbase.io/script.js https://safepasswordchecker.hashbase.io/script.js

LeoPanthera 7y ago

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

tomglynch 7y ago
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!"

lysp 7y ago

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.

stephenr 7y ago

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.

tomglynch 7y ago
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.
- stephenr 7y ago
  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?