Should one reject login attempts when the correct password is newly added to a password deny list?

Question

Best practices say that when users choose a password (at signup or when changing an existing password), the application should reject that password if it appears on a list of passwords known to be unsafe. For example, NIST Special Publication 800-63 from 2017 says the following (emphasis mine):

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.

Let's say I implement this using Have I Been Pwned's "Pwned Passwords" API.

Now what happens if a password used by one or more of my users appears¹ in a data breach? Obviously, the password should now be considered "definitely unsafe"²: sooner or later, attackers will include that password in credential stuffing or password spraying attacks.

Following the NIST advice, my application would reject entering such a password on a "change password" form (see above: "When processing requests to (...) change memorized secrets, verifiers SHALL (...)").

However, if nobody was alerted of that particular password being breached (neither me as the application owner nor every user using that password), that alone will not help: Attackers can still use that password until affected users have changed their password. But that may or may not happen. What's worse, for seldomly-used applications, a lot of time may pass until they log in the next time, so simply displaying a warning on login will not shorten the attack window.

Therefore, I believe that my application should reject login attempts which use a breached password:

• That way, an affected account would effectively be locked from the moment its password appears in a breach corpus. As no attacker could gain access, breach corpus passwords become useless to attackers.³
• The application would reject the login attempt with the same reaction (visible message and API response) as if the wrong password was used. This avoids giving the attacker the potentially useful information that this username/password could be used elsewhere.
• When a login attempt is rejected due to this, the application could send an email to the account owner informing them of the situation and asking them to use "reset password" functionality. The email would be sent asynchronously to minimize the risk of timing-based information leakage.
• To avoid repeated emails, the application would also set an appropriate flag on the account.

What I tried

I could not find any mention of rejecting login attempts related to breach corpuses. I thought about whether the word "establish" in the NIST guideline could mean "login", but I doubt that as the rest of that section would not really fit that interpretation.

When processing requests to establish and change memorized secrets, verifiers SHALL compare the prospective secrets (...)

Questions

1. Is there any official/established/popular advice on the topic of rejecting login attempts due to passwords occuring in breach corpuses (as opposed to rejecting password change attempts)?
2. Is such an approach advisable in general?
3. Does this (my approach outlined above or the general idea) have any drawbacks or caveats one should consider?

Footnotes

1. For this, it doesn't matter whether it was indeed my user's data or someone else's data that appeared in the breach.

2. I am aware that just because a password does not appear on breach corpuses, it does not mean it should be considered safe.

3. Only the most fresh breaches, the ones that did not yet make it to HIBP, would still be useful.

Answer 1

There is no single right choice, i.e. it depends on the details of your actual use case, as often it is a trade-off between usability and security. Some aspects to consider:

• If the account is valuable to the user, then the user might actually be thankful for this protection. But in the other case, you might lose a customer, i.e. lost value for you.
• If lots of damage might be done with the account it is important to you as a service to protect the account, so blocking the account might be acceptable even if it might mean losing users.
• There might be less severe options to fully blocking the account immediately, like limiting what can be done with it. This is more usable for the customer, so you might keep the customer while still protecting them.
• Given that passwords are often reused, it might not be safe to trust the user's email for password resets, since the email account might be compromised too. So you might need to employ more secure identity verification, which will result in even less usability for the user.
• You might actually be overwhelmed with users contacting your support, so be careful when enabling this protection for all users at once.
• Also be very careful on how you communicate to the user the reason for the password reset. It could be easily misinterpreted as a password leak on your side, which would be bad PR for you.

There is actual research into this topic, like this project (sorry, only in German - but there are also some academic papers in English linked). The points above are based on information I got from people involved in this research project.

Answer 2

What is your threat model - how much damage can be done with a compromised account?

The best option, if you do have an additional/stronger authentication method, like 2FA or biometric, is to suspend high-impact operations until the user reauthenticates with said stronger method.

For an app that can do financial damage to the user, this should already be built-in. For apps that combine financial and non-financial services, it's good practice to have two levels of authentication, for read-only access and for transactions.

As a general rule, for anything unimportant enough to only be protected by a password, denying access in the event of a weakened password is not normal practice. This is driven by the same usability considerations that have led to the decision to rely on weak authentication (password only) in the first place.

For anything important, your 2FA should be a stronger temporary protection than email-based password reset, as the second factor is more independent than email and site password.

For very high security scenarios, you may want to make use of this marginal bit of security, the hope that the email is safe. But 3FA (like third-party biometric verification) is a stronger security guarantee still, so again makes the extra security from the email password insignificant.

Answer 3

I would advocate against rejecting the login attempt. That would be giving the wrong signal to the user.

Much better to communicate it without disabling their account. But do add a banner with information for the user. With a link to explain what you found and what that means.

Basically we want to give the users the feeling we are there to protect them… and not there to make them do things we want.

Answer 4

Remember that availability is a security requirement. If you are a bank and your security policy prevents a customer from paying his rent, that is a failure of your security policy. Of course there are tradeoffs, but you have to at least consider a hit to availability as something to be avoided. The appropriate balance depends on the risks.

For this, it doesn't matter whether it was indeed my user's data or someone else's data that appeared in the breach.

I'd suggest that is actually not true. If it is someone else's data, the response you suggest would almost certainly be disproportionate. There is no reason to expect that an attacker would associate that new, and presumably very rare, leaked password with this account. They'd be more likely to try "Password" or "monkey" just because that has a better expectation of success. Even if they're only trying new leaks, you'd expect to notice them trying many thousands (or, ten and then you block them) of newly leaked passwords before getting close.

On the other hand if the password leak was associated with the individual, none of that works. If the attacker has the password paired with an identity (e.g. an email address) then it goes straight to the top of their attempt list. You couldn't expect any warning shots. As such, locking them out and contacting them out-of-band to verify their identity and reset their authentication is exactly what you would have to do.

If you don't know which case is which, you can make a probabilistic risk argument in favour of treating it as serious. Just remember to count the cost to availability and develop a smooth recovery process.