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