Is there a reason why I should not use the HaveIBeenPwned API to warn users about exposed passwords?

Question

There's lots of talk about the HaveIBeenPwned password checker which can securely tell users if their password appears in one of their known data dumps of passwords.

This tool has a publically available API behind it which websites/apps/etc are free to use to allow their users to check their passwords, but from what I can see all the listed applications are specifically email/password checker tools.

Never have I seen or heard of a user entering a password into a website while creating an account and it then gives them an error message detailing that their chosen password can be found in a well-known data breach.

If I were to create a website, would it be a bad idea to automatically check my user's passwords against HaveIBeenPwned's tool as an additional safety precaution and to require them to pick a password which the site doesn't know about?

Answer 1

Latest recommendations from the NIST (SP 800-63b Section 5.1.1.2; see here or here for a summary) actually suggest checking user passwords against lists of known compromised passwords, so doing just that is actually in line with current best practices. It's also much better than requiring passwords to meet certain "rules" (which the NIST now recommends against). HIBP is just one way (and probably the simplest way) of doing this in practice. It only requires sending off the first 5 letters of the hash of the password, so actual risk to users is practically zero. So yes, please feel free to do it if desired.

As for why a particular organization might not do this, I'm sure that varies wildly from site-to-site, but I think it's a safe bet that it boils down to the usual suspects:

1. Security is an area where many like to skimp, and implementing such a system takes additional effort.
2. It takes time for new best practices to become common knowledge for institutions
3. It takes even more time for institutions to get caught up with best practices
4. Every developed feature has costs: money in terms of engineering time to develop and maintain, lost users who don't understand or wish to follow the rule (h/t @Woohoojin), etc. Organizations may not consider the added benefits to be worth the costs.

To be fair, none of my systems do this yet, so you can add me to #3 or #4.

Item #4 is worth a bit more mention. The costs of implementing this are obvious—it takes developer time to build and maintain any feature. The benefits are much harder to quantify. Of course when it comes to security issues, many companies make the mistake of assuming benefits are zero and therefore skimp on security (see point #1). However, this is one feature in which the benefits are likely small. There are often real costs to a business related to the compromise of user accounts (more customer support, perhaps rolling back transactions, etc...), but as long as the compromise was due to the user's own mistakes (in this case, by choosing compromised passwords), a business is unlikely to see any direct liability and therefore will probably avoid any larger costs. As a result, features like this may not be worthwhile for all businesses to implement—it's always up to each business to weigh for themselves potential costs and benefits.

Answer 2

Because the cost of doing so is non-trivial:

• people who don't understand how HIBP works will assume that you're not handling the passwords properly (example), and you'll have to deal with complains and misguided criticism.
• you'll have to periodically update the code when HIBP API changes, or the service shuts down and you'll have to migrate to a new one.
• any slowdowns or downtime on HIBP will mean your own site will slow down. Especially if you want to keep checking existing passwords against new breaches.

At a later time, it is likely that such a feature will be expected from a website which claims to take security seriously. Then everyone will be implementing it because the costs outlined above will be outweighed by the benefit of looking like a secure website.

And yes, there are companies who have already implemented the HIBP check.

Answer 3

You did not put a country tag, which can influence what you can do or not. You seem to be from the UK, though - which apparently has a more relaxed way regarding the points below.
Also you seem to want to do the check at login time - that would make my comments below less useful.

All this said, taking the example of France or Germany, you need to be extra careful presenting a solution which tracks users' activities. You can have the best intentions in the world, there are some people who will not appreciate.

Specifically, if you are checking leaks against the users professional email you are fine (I am assuming you work in information security for that company). You have an obligation to protect the interests of your company so if a professional email (and possibly the associated password) is being misused then you are in the green.

Be careful extending this check to non-professional activities. You may want to suggest people to check themselves their personal emails against HIBP but that's all.

YMMV - this is a consensual position I took after zillions of discussions with legal, privacy and labour law experts; each of whom had their own opinion on the subject so I am treading lightly.

Answer 4

If I enter a password, you should not hand it over to a third party under any circumstances. Even in hashed form. It will always give an attacker an opportunity.

Now if you can get a complete copy of the password database, and store it together with the rest of your password handling code, so that it can be checked without any outside communications, that could be worthwhile.

Answer 5

No, because by sending the SHA-1 of the password to a third-party (HIBP), you are exposing your users to MITM attacks. SHA-1 is not secure against a well-funded, nation-state attacker.

The authors of the linked paper estimated the cost of mounting such a SHA-1 collision attack to be $75,000, assuming prices from a public cloud services. However, you could perform the same computation on a supercomputer for only $1,395.60, a small sum when the stakes are high. Based on the leaked information about the user, the following could happen:

• Saudi Arabia decides to kill the user
• China steals the user's intellectual property
• Russia threatens your user using the kompromat gained

Such an attacker could wiretap the target's traffic, then later sort through the contents of the traffic to look for weaknesses.

Readily available consumer tools can sniff, intercept, and modify HTTPS traffic. Unless, HTTPS certificate pinning is used and that certificate is not compromised, a determined nation-state attacker can use a compromised CA to intercept HTTPS traffic.

A better way to do it is to have a database of cracked password hashes on the server that you use to verify passwords.

---

The first 5 characters is too much information to give away. It raises attacker cost. That turns a secure password into something crackable.

Answer 6

Not only to make your users more secure but it makes your site more secure as well - if your (emphasis added for clarity) users are breached it will reflect on you (because it is your platform that might be attacked due to user credentials being compromised) regardless of whether the weakness is with you.

It secures your platform and the information you hold as much as it secures your clients. Under the Australian Privacy Act, if you fall under the Privacy Act you are required to keep the personal information you hold - secure. Hold is defined as control or possess. So companies are being found to breach the Privacy Act even though it was a third party breach that occurred because they "owned" the data - source see the Blood Cross comments by the Privacy Commissioner - https://www.oaic.gov.au/updates/news-and-media/australian-red-cross-blood-service-data-breach/

So cloud providers are just as responsible for the breach as the SAAS provider they host and people who's credentials were compromised. Even though they might not control security around the servers etc. Welcome to Australia!

Therefore by increasing security around your platform you are protecting yourself - assuming you have similar laws.

Also, it serves as an education to users - they learn that reuse of credentials is not safe.