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: 
It would do you well to read up on [why Troy created the pwned password list in the first place](https://www.troyhunt.com/introducing-306-million-freely-downloadable-pwned-passwords/).

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".
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](https://web.archive.org/web/20040712152833/http://csrc.nist.gov/publications/nistpubs/800-63/SP800-63v6_3_3.pdf) 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.