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.

  • 1
    This question may give you an insight on how bad a partial hash leak would be, as would be the case if HIBP were hacked.
    – user163495
    Commented May 26, 2020 at 6:56

2 Answers 2


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.

  • Matching a partial match doesn't give the attacker much at all. The reason is because there is at least one entry in HIBP for every partial hash. Therefore the fact that a given password has a partial hash match to HIBP only means that the password has a hash - aka this fact is literally useless. Commented May 28, 2020 at 1:43
  • Moreover, if you don't allow users to register with a leaked password then all passwords in the HIBP password list are entirely useless even if you could brute force some subset of them. Finally, it would likely be impossible to correlate lookups in the logs stolen from HIBP with users in your system, so a brute force would be impossible even if you could get actual passwords out. Commented May 28, 2020 at 1:48
  • Given that over 99% of the HIBP corpus has been independently cracked (because the hashes are unsalted), the fact that there is a partial hash match is not entirely useless (search for "pwned" here: hashes.org/leaks.php). And since passwords are often reused, narrowing down the potential passwords to just a handful is an excellent way to get past most web-based services' anti-bruteforce thresholds. Commented May 29, 2020 at 2:44
  • Agreed; Also (in response to Conor) a partial match against the database significantly narrows down the number of hashes that would contain the correct password -- less cracking effort. not allowing your users to register passwords in HIBP requires you to check whether password candidates are there, making the database ... useful. correlating lookups may not yield usernames but knowing that a password (or a set of passwords) is used on a website is a significant advantage against knowing nothing.
    – Pedro
    Commented May 29, 2020 at 7:45

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.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .