Feature request: adjustable thresholds on how many times a password has been in a breach according to haveibeenpwned

[fungiboletus]

Is your feature request related to a problem? Please describe.

Kratos is not accepting any password that has been in a security breach in the past according to the great haveibeenpwned website. It sounds good on the paper but in practice I feel like too many people will simply give up registering, or set a password that they will immediately forget.

Describe the solution you'd like

Requiring passwords that have never been in a breach is a good idea in many scenarios. It should probably be the default, but I think a configurable threshold can be a good usability improvement in scenarios where a relatively weak password is acceptable.

Describe alternatives you've considered

–

Additional context

I don't have data to back up my claims but here is what I found with a quick search:

Troy Hunt's point of view : "it depends"

The true cost of unusable password policies: password use in the wild: "policies should be designed using HCI principles to help the user to set an appropriately strong password in a specific context of use."

Rethinking Password Policies:

"Is the user able to understand what is required of her; Can the user understand how to use the
security mechanism properly, recognize when she’s failed, and understand why?

• Is the user capable of using the mechanism properly?
• Does the user understand the goal of the security mechanism;
• Is the user motivated to follow the security requirements?
• Do the requirements and interface match the user’s understanding of the security goals?"

Encountering stronger password requirements: user attitudes and behaviors
"Some users struggle to comply with new password requirements. Most users created their new password in a single attempt, and believed they would be able to login in one try. However, 19% of users reported already forgetting their new passwords. " (explicit rules in this test).

[aeneasr]

Thank you for these thoughts. I think it's a pretty bad idea to allow breached passwords but I understand that in certain scenarios the company/provider is more concerned about conversion during sign up (no judgement! - that's the trade-off between UX / conversion and security).

Please note that links / references (except the first by Troy Hunt) talk about password complexity mechanisms, which are no longer considered best practice because of the issues mentioned in these references. The same thing applies to expiring passwords, which are also no longer considered best practices, as referenced in your post. It's important to note though that these links are also from 2010/2013 and things have changed quite a lot since then! Those studies are not valid for a list of leaked passwords and user IDs.

If this was implemented, we would need a hard upper limit, for example 5 breaches. This might seem arbitrary - it is - but that's the problem with having this count. What's an ok amount of breaches? 1? 2? 10?

I think checking if an email address has been in a leak, and if the password was breached should give 100% certainty that the password must not be used. Maybe it makes sense to have that check in place and allow up to 2 or 3 breaches if the email has not been leaked before. This would reduce the attack surface while not disallowing the whole HIBP database.

Implementation would be pretty forward, basically adding "HIBP" email lookup to the password validator and making this configurable!

[crofty]

I'd also like this limit to be configurable, but ideally without a hard limit, just a sensible default. That would enable the choice about the trade-off between conversion and security to be made on a per app basis.

[aeneasr]

What would be a sensible default for you?

[crofty]

I think 0 would be a sensible default. This maintains the current behaviour but would allow apps to set it higher if they wanted to be more liberal with the passwords that they accept.

[aeneasr]

And what's the reasoning for not using a hard limit? I think that some people might just disable this completely then?

[crofty]

To me it just seems like the sort of decision that should be configurable at the app level as each as will have different tradeoffs to make when it comes to security vs ease of signing up.
I think it would be difficult to decide on a hard limit that would be suitable for all apps.

[amorey]

I'd also like this to be configurable