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?


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.

  • 1
    "An user wants to create an account on our website." - Are you sure they want to? I question the premise of someone wanting an account and not wanting a good password. If it's an option, allow websites to be used without accounts. If it's an option, allow "login with Google/Facebook/whatever".
    – domen
    Oct 8, 2018 at 14:54
  • 1
    "We have some criteria such as length and special characters" You shouldn't have any rules regarding special characters anymore. The latest NIST standards advise against it, for good reason - when forced to add special characters people don't actually do it randomly, and it doesn't really make the password any stronger (it just inconveniences the user). Minimum password length check is very good, and checking against leaked passwords is excellent. That's all you need. Oct 8, 2018 at 20:24

4 Answers 4


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

  • That is a very interesting approach to it. The most secure way would definitely be to simply block the passwords that are found in Troy's list and force the user to make (generate preferably) a new one. Unfortunately it's impossible to force our users to use 3rd party authentication, because we need the logins for mails accounts et cetera. Oct 9, 2018 at 6:28
  • google and facebook login should not be used for anything you want to be secure. Neither verify identity or expire authentication and you lose controll of the whol;e process. Oct 12, 2018 at 11:18
  • 1
    Can you expand on "neither verify identity?" Most websites only require an email address to sign up, and only a username or email address to log in afterword. Signing in with Google or Facebook changes nothing in that area. For "neither...expire authentication" you may have a point, if you want to automatically log anyone out. But changing your Google password can definitely log you out of other sites. And "losing control of the process" is kind of the point...you're trusting Google/Facebook to do it better than you could, so you don't need to bother.
    – Ben
    Oct 12, 2018 at 16:09

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.

  • It's very common today, that companies can be held liable for bad user passwords. Or at least get a very bad public standing. It's seen a lot in the news lately. However, you also have to factor in, that it's the user's responsibility to use a strong password. Even if the user thinks it's safe, it could still be bad, because it was found in a breach. I would still love to see, if some of the large companies thought about this and what they determined. Oct 8, 2018 at 10:09

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.

  • "While I expect that the number of passwords cited by haveIbeenpwned is the number of instances rather than unique values" your expectation is incorrect. Troy really has collected half a billion unique passwords from breaches. You can download a list of the SHA1 hash of each one of them and a count for each hash for the number of times that password got used.
    – Ben
    Oct 8, 2018 at 17:54
  • "it still suggests that a large proportion of password proposals will find a match in the database." Yes, and that's the point. If NISTs research suggests that there are only ~2 million passwords that people actually use, then it is terribly easy to brute-force those passwords, which is exactly the problem that the OP is trying to address. All the more reason, therefore, to restrict such passwords. Oct 8, 2018 at 20:22
  • In my opinion, the goal would be to protect ourselves. An user is only as secure as they make it themselves. Even if they pick a very, very long and complicated password (generated), their account isn't secure if they send it to people on Facebook. We can't stop people from acting stupid, unfortunately. And some services just simply won't do two factor authentication because of how they're built. Oct 9, 2018 at 6:30

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.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .