Xjyuk

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. Is there a reason behind this?

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?

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. So yes, please feel free to do so.

As for why you don't see this more often, 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 costs money in terms of engineering time to develop and maintain, and may organizations may not consider the cost worth the benefit.

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 quantity. 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.