[dijonman2]

> The third thing is to match against specific leaks. E.g.: if you have [e-mail] and there is a leak of his email and password where the password matches your records, force a password change immediately.

I’ve wanted to do something similar but how would you do this without direct access to HIBP’s data?

I don’t want to send customer email addresses to a third party, at least not without a contract.

[jeroenhd]

For what it's worth RE: HIBP, the lookup is never actually done on an email address. If you use the API (https://haveibeenpwned.com/API/v2#SearchingPwnedPasswordsByR..., or https://api.pwnedpasswords.com/range/3E398 to see the API result), you transmit 5 characters of the SHA1 hash of the email address and check if the full hash is in the list.

This makes it possible to use the API without worrying about user privacy as long as you keep checking the email addresses, even after indicators of compromise. Suppose [e-mail] is in the list is the only email address with 0xABCDE as the start of the hash, and the full hash being 0xABCDE0000; now [e-mail] happens to have the hash 0xABCDE1234. You transmit ABCDE to the backend, but even with the unique five letters of [e-mail], how can the server possibly know if you're checking [e-mail] (a listed entry) or your own address? The server provides the list of hashes (only 0xABCDE1234) and you verify on your end that 0xABCDE1234≠0xABCDE0000, proving that your email is unlisted.

On average, the returned amount of hashes is claimed to be 381-584. That means that even if your customer is on the list, they're at best one of the ±478 hashes (on average) in the response if they're even listed at all!

The full explanations is here: https://www.troyhunt.com/understanding-have-i-been-pwneds-us..., it's worth a read if you're interested. In practice, I wouldn't worry about your customers' data in this case, because you're not really sending anything identifiable to a third party.

There are less privacy conscious APIs to HIBP, but the range search is probably the easiest and most private way to get the checks done.

All of that said, I use random passwords for every service I use and I'd very much like to opt out of your auto reset system. I'm in favour of adding the feature (more websites should, in my opinion!) but I don't like to be forced to change my already unique password if I don't have to.

[TheMaskedCoder]

> you transmit 5 characters of the SHA1 hash of the email address

You don't use email addresses at all with Pwned Passwords. The documentation says "first 5 characters of a SHA-1 password hash", not email-address hash.

HIBP does not have a way to search for which password hashes are associated with a given email address, as this would be far more useful to attackers than to victims. The only data that Pwned Passwords exposes is a list of password hashes and the number of times that hash was used. The expectation is that even if that leaked password was actually for someone else's account, you still shouldn't be using it.

[jeroenhd]

Whoops, you're right, got the API confused. You can't just search for email addresses.

Still, though, you can implementtthis check every time someone logs in (and the password is transfered over the wire) which should catch most bad passwords/password reuse cases.

[dijonman2]

I had no idea, thank you for opening my mind to this!

[jve]

You HAVE direct access to HIBP data. Albeit hashes only which are enough to tell if password has been compromised before or not. You can download pwned passwords list and do checks locally: https://haveibeenpwned.com/Passwords

[Scion9066]

If you don't want to send stuff to others, then you would generally need to either get the email address data another way (e.g. collecting the data from breaches yourself on behalf of your org) or download the Pwned Passwords data and setup a system to check against compromised passwords locally.