Is there a reason why I should not use the HaveIBeenPwned API to warn users about exposed passwords?
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:
- Security is an area where many like to skimp, and implementing such a system takes additional effort.
- It takes time for new best practices to become common knowledge for institutions
- It takes even more time for institutions to get caught up with best practices
- 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.
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.
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.