Is this (explained in body) a possible attack vector when using haveibeenpwned API?

Question

I'm currently working on understanding and contemplating to implement password strength validation for sign ups in my app, to include checking haveibeenpwned if entered password is compromised elsewhere.

I understand the process involves the site sending a partial hash of the password to HIBP and HIBP will respond whether it's pwned.

I am also assuming that it is possible that HIBP stores logs of my API request and that it may contain information leading back to my app.

If HIBP gets hacked, and attacker gains access to the above hypothetical logs, assuming that it contains all the information in the original request – the partial hash and where it came from (my site), can the attacker construct an attack on my site is this way?

1. Hash the passwords in the list of pwned password and get a list of hashes
2. Match the partial hash he has with those in the above list and derive a refined dictionary of N number of possible passwords with same partial hash
3. Try the passwords on my site

I am aware at every point in the above, measures can be put in place to mitigate each, e.g. 2FA. But it is not my objective to ask for how to secure my sign up, but to validate my concerns with using HIBP and whether there's an attack vector to be considered.

PS: I'm not a security expert but I do know how passwords and hashes work. As HIBP is new to me, I don't fully know how it works and all the features of its API. Pardon me if I made wrong assumptions.

Answer 1

I'd say this is a viable attack scenario provided the attacker does have control over haveibeenpwned.com and its list of hashes. They can match the partial hash, collect all results and try those.

In parallel the attacker can run a long-term cryptanalysis against the entire database which would yield a proportion of those entries in plain text, potentially enabling a partial list corresponding plaintext matches to that partial hash thus greatly simplifying the attack.

As in many other cases, you'll have to trust the provider if you are to use the service. The service being compromise is no more likely or unlikely than other services and it is dealing with quite sensitive data (hashed passwords). Just something to take into account for your risk assessment.

What I have seen in the field is people cloning the hibp SHA1 database and testing locally.

Answer 2

Every decision in Information Security revolves around managing risk. If you ask me whether your hypothetical threat can materialise in an actual attack vector, I would say that theoretically it is possible, but practically highly unlikely.

The risk of an account compromise as a result of your application's users choosing a weak (or breached) password upon registration is definitely more significant and, therefore, you should manage that risk by implementing the necessary countermeasure. Here, HIBP is one countermeasure (among others such as password complexity requirements, 2FA, etc.) which reduces that risk to tolerable levels, but some form of residual risk still remains because of various other threats, including the one you mentioned. Having said that, you can further reduce the residual risk by downloading the PwnedPassword file and load it on a local database within your network.