Is it a good idea to check if the password provided at registration is leaked on any lists? And then, prevent the user from using it?

Question

A while ago, I was tipped off that it's a good idea to check if the password provided at registration is contained in any list of leaked passwords. I'm not in the information security field, but I really like to take aspects like this seriously, I always think about the issue of passwords. The website haveibeenpwned provides an API to do such a task, which is very nice.
I'm not sure if this would impact my application in a positive way, I think it would. However, I would like to hear from those of you who work with intrusion testing.

You might be asking yourself: why is he talking about intrusion testing if the idea is to prevent something when signing up? Well, the idea is that if the user is not able to use passwords that have already been leaked, then an attacker will have less chance in password guessing attacks, for example, in a dictionary attack. Of course, to deal with such attacks, it is not enough just to implement this mechanism mentioned in the question, I know it's not enough, but it would be one more mechanism that would make the application more reliable.

After performing a search, I found an interesting resource from the Okta Developer website.

Not too long ago, the National Institute of Standards and Technology (NIST) officially recommended that user-provided passwords be checked against existing data breaches.

The new NIST recommendations mean that every time a user gives you a password, it’s your responsibility as a developer to check their password against a list of breached passwords and prevent the user from using a previously breached password.

For instance, let’s say that your password, “fdsah35245!~!3”, was breached in the well-known Sony data breach back in 2014. Once those passwords were leaked, attackers would download the compromised passwords and use them to try to log into other user’s accounts.

So, as mentioned in the quotes, the idea seems to be good and efficient, however, maybe this generates usability problems, can it happen that the user does not feel comfortable with such a mechanism? Anyway, this seems like a good idea, implementing this mechanism could make the application more secure, but maybe I'm wrong?

Let me know what you think about it, my goal is to become a better developer, I don't like the idea of having to create vulnerable apps.

Answer 1

As you noted, the current recommendation is to do this, and there exist both lists and APIs (e.g. from haveibeenpwned a.k.a. HIBP) to support this. It provides much stronger protection than simple "complexity" rules (which often lead to a false sense of security, or even using weaker passwords than one otherwise might, because the extra changes to satisfy such requirements are hard for a person to remember).

As for making people uncomfortable, if you tell somebody that their candidate password is on a list of known breached passwords, you're doing them a favor. Obviously you should word it in a way that is clear what the error is without appearing disrespectful (e.g. "This password is known to have already been used, and compromised, on another site. Pick a new, unique password.", possibly with a link to HIBP's Pwned Passwords page or similar).

You can avoid actually sending the password, or even its hash, anywhere by downloading the list of breached passwords and checking against it locally, though then you'll want to update the local list when new breaches are added (HIBP supports this, or there are other password lists). Mind you, the way the HIBP API works is actually very good for not revealing the password (it takes the candidate password, hashes it client-side, and sends only a severely truncated version of the hash to HIBP's servers, which reply with a list of known passwords that have that hash fragment for client-side comparison against the user-submitted password). Nonetheless, some people might still prefer their passwords not leave your system in any form.

Do note that if you use a breached password list and a complexity requirement, you're wasting your own and your users' time. Just have a length requirement (8 characters is the practical minimum for security, but longer is better), no character requirements or restrictions, and check only that the password is not on any breach lists and is not otherwise predictable (e.g. doesn't contain the site name, user's name, etc.).

---

Here are the relevant guidelines (from section 5.1.1 of NIST's SP-800-63B, last updated in 2020):

When processing requests to establish and change memorized secrets, verifiers SHALL compare the prospective secrets against a list that contains values known to be commonly-used, expected, or compromised. For example, the list MAY include, but is not limited to:

• Passwords obtained from previous breach corpuses.
• Dictionary words.
• Repetitive or sequential characters (e.g. ‘aaaaaa’, ‘1234abcd’).
• Context-specific words, such as the name of the service, the username, and derivatives thereof.

If the chosen secret is found in the list, the CSP or verifier SHALL advise the subscriber that they need to select a different secret, SHALL provide the reason for rejection, and SHALL require the subscriber to choose a different value.

...

Verifiers SHOULD NOT impose other composition rules (e.g., requiring mixtures of different character types or prohibiting consecutively repeated characters) for memorized secrets. Verifiers SHOULD NOT require memorized secrets to be changed arbitrarily (e.g., periodically). However, verifiers SHALL force a change if there is evidence of compromise of the authenticator.

Verifiers SHOULD permit claimants to use “paste” functionality when entering a memorized secret. This facilitates the use of password managers, which are widely used and in many cases increase the likelihood that users will choose stronger memorized secrets.

Answer 2

Hmm..., this is not a stupid idea: we are already used to constraints about a minimal password length or a minimal number of character classes. Having a black list for passwords known to be present in lists used by password crackers should not unsettle too much users.

IMHO, the real problem is that those list could change rather quickly. And the rule if often that the more constraints you put on a password pattern, the longer you allow the user to keep it.

For that reason I would prefere the idea of passing well known password crackers (John the ripper, etc.) on the user databases on a timely base and warn users by an automatic mail that their password has been automatically guessed and that they should change them. Whether you make it mandatory or advisory could depend on the sensitivity of the data and the user experience you want to offer