Dealing with users who reuse bad passwords

Question

What is the best (or good) practise to deal with users, who are determined to reuse their old password, whether it be good or bad? Or simply use a bad password?

Scenario:

A user wants to create an account on our website. We have some criteria such as length and special characters. The user then enters their usual password, which we look up on https://haveibeenpwned.com/Passwords to see if it has been in any breaches. In this case, the user's password has been leaked in the past.

At this point, we have a couple of options:

1. Tell the user in a friendly way, that their password is insecure, because it has been leaked before
2. Tell them 1. and tell them they can't use that password, because it could put their account at risk
3. Tell them 1. but allow them to use it, if they check a checkbox saying "I am aware that I am using a password that has been leaked"

Obviously, the best possible thing is to not let them use that password, however, some users might not tolerate that. I certainly wouldn't, but it completely depends on the case. Option 3 is interesting, because if they get hacked and sue us for allowing them to use a bad password, they can always claim they didn't see the checkbox.

Have there been any papers on this, with any kind of proof, that proves that one method is better than the other? Any statistics on the matter?

I know Microsoft enforces the good old "we noticed you tried to change password to a previous password you had". Certainly some thoughts must've went through their minds, if they disallow users to use old passwords.

Answer 1

It would do you well to read up on why Troy created the pwned password list in the first place.

NIST guidelines are pretty explicit what to do: "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." (emphasis mine)

Block the bad password. Tell them why you're blocking it. For bonus points, suggest a randomly generated password they can use instead, or link to a site describing how to generate one (or provide a list of password managers).

Or, as others have said, use some sort of 3rd-party authentication, e.g. "login with Google" or "log in with Facebook".

Answer 2

If you can be held liable in any way for any damages as a result of data leaked from your website, even though it could be traced to reuse of known passwords, I'd always go for the option of forcing people to choose another password.

Most people will always go for the easy way out, so option 1 will result into them still using the bad password, as will option 3. The only way to make sure you will not suffer the results of their bad handling of passwords, is by forcing them.

Answer 3

Currently, haveIbeenpwned has 517,238,891 passwords. To avoid over-complicating things, lets assume that they are all 10 characters long from a set of 86 characters. That's 1.37e19 possible passwords if they were random, but Nist's estimate suggests that the number of passwords users will actually choose (4 bits for first character, 2 bits for chars 2-8, 1.5 bits for chars 9 on) is less than 2,100,000. While I expect that the number of passwords cited by haveIbeenpwned is the number of instances rather than unique values, it still suggests that a large proportion of password proposals will find a match in the database.

The risk arises from an attacker knowing a combination of a password and a user id.

Based on the above, the reason for rate limiting authentication attempts should be obvious.

Passwords suck.

You didn't state if your objective is to protect your users or to protect yourself. There are ways to transfer liability by:

• reminding users about good password practice (don't reuse passwords) and require them to acknowledge the message. You can always check later - or even check at the time if the password is in haveIbennpwned's set without using that to drive the interaction flow
• rely on someone else to manage the authentication - typically using openID

Nor did you state what the nature of your relationship with your customers is. You may lose business by making registration too onerous.

While no one can give you a definitive answer as the "right" solution, if you were to run AB testing of the different approaches then you would be able to at least measure the effect on the customer's perception of your site.

Answer 4

I think you only have two options that make sense:

1. Block the password, and tell the user the reason in a very detailed and comprehensible way. That is, tell them their password is considered insecure because it is included in a database of passwords that are now considered insecure. They need to use another one. They will probably understand and might even be glad they learned something new.
2. Let the user choose whatever password they want, as long as it has enough entropy (check their length, etc.) and you have a bruteforce prevention system (long time between failed logins, CAPTCHAs, banning IPs after too many attempts, etc.).

Why do I believe that option #2 is not insecure?

1. Unless my impression and my calculations are wrong, I do not believe online bruteforce attacks are going to try too many passwords. They will just try a few passwords (the most common ones), and then move on to another account to do the same. At the moment haveibeenpwned seems to have half a billion "insecure" passwords. So for example, at a speed of 1 password per second (considering delays, captchas, blocks, bans, etc) it would take about 15 years to try them all. You might be able to speed that up using multiple IPs, etc., but it would still take too long. Nobody would do that, maybe not even if it was a targeted attack (they will probably consider other options).
2. For offline attacks, which can be very fast, the attacker is probably going to try all the passwords in the haveibeenpwned list, but they won't probably stop there: they will try more, maybe some variations based on that list, and guess what? When a user is fond of a certain password and is forced to change it, they might just use a slight variation of it. Also, if the attacker is able to bruteforce the passwords offline, then you might have worse problems: your software probably has some serious vulnerabilities that allowed it, other data might have been stolen or compromised (including the software itself, so the passwords might have been read in plaintext at every login), etc.

To tell you the truth, I'm usually more worried about the fact that users often use the same password everywhere, or slight variations almost everywhere. And unfortunately there's no way to force such users to stop doing that.