MSC2000: Server-side password policies

[babolivier]

Rendered

[lampholder]

I HAVE OPINIONS 😁

We want our users to have a good experience and strong passwords

A good UX means:

• you know what the password requirements are up front
• you get good, quick feedback (in your own language) to make it easy to select a strong password
• the client must never tell you that your password is good only for it to be rejected by the server

Strong passwords means:

• mathematically difficult for a computer to guess

My thoughts

I'm nervous about our programatically describing password complexity requirements. Over time, as new requirements arrive (no repeated alphabetical/keyboard layout sequences, none of your past three passwords, no passwords with the current date in them, etc.) this will be harder and harder to describe in a password complexity DSL that then has to be interpretted in the same way across all clients. For this reason, I would rather all password validation happen server side.

We could support server side password complexity validation by exposing an additional API, to which you can submit a password and it will respond with feedback. This feedback could take the form of:

{
    "acceptable_password": false,
    "feedback": [
        {
            "code": "E_KEYBOARD_SEQUENCE",
            "description": "Straight rows of keys are easy to guess"
        },
        ...
    ]
}

Then the new password complexity route, GET /_matrix/client/r0/password_policy, could return something like:

{
    "policy": "namespaced.policy.name",
    "description": "I am a string containing a prose description of the password complexity"
}

How to provide decent internatioionalisation of ^ is an outstanding issue.

The existing password setting/resetting endpoints could still reply with the specced weak password error code, but would ideally also include the same password complexity feedback warnings from the complexity validation API.

[babolivier]

IRL chat concluded on that I'll update the proposal so that it keeps parameters in the response for /password_policy but defines mode precise error codes so that the client can handle both display and l18n on both ends.

[turt2live]

mostly have comments on structure - the concept is a great addition!

[joepie91]

* you know what the password requirements are up front

I think this objective is mutually exclusive with actual password strength. Pretty much every password policy that's sufficiently easy for the average user to understand in prose, is going to be insufficiently accurate in terms of guaranteeing a minimum password complexity. See also zxcvbn, which is mentioned in the MSC.

I'm also not sure that there's an inherent benefit in the requirements being known upfront, so long as the complexity feedback is easily understandable and actionable.

[nadonomy]

I'm also not sure that there's an inherent benefit in the requirements being known upfront, so long as the complexity feedback is easily understandable and actionable.

From doing UX research in person— I've witnessed non-technical users struggle when they can't conceptualise the password they want to use before typing it, leading to painful guessing games. Similarly, I've seen the same frustrations from technical folk using generated passwords from password managers.

[joepie91]

From doing UX research in person— I've witnessed non-technical users struggle when they can't conceptualise the password they want to use before typing it, leading to painful guessing games. Similarly, I've seen the same frustrations from technical folk using generated passwords from password managers.

This sounds very much based on experiences with arbitrary-password-rule-based systems (as opposed to complexity analysis, like what zxcvbn does), and half the reason for existence of zxcvbn is to prevent the situation where people are told a password is 'bad' for arbitrary reasons.

Do your observations hold up as well in a scenario where the password quality checker doesn't over-catch, and thus the user is only told that a password is bad when it really is obviously bad?

(I'm particularly wondering in the context of password manager usage, because zxcvbn basically never turns down a password from a password generator, given that they are inherently random.)

[nadonomy]

From doing UX research in person— I've witnessed non-technical users struggle when they can't conceptualise the password they want to use before typing it, leading to painful guessing games. Similarly, I've seen the same frustrations from technical folk using generated passwords from password managers.

This sounds very much based on experiences with arbitrary-password-rule-based systems (as opposed to complexity analysis, like what zxcvbn does), and half the reason for existence of zxcvbn is to prevent the situation where people are told a password is 'bad' for arbitrary reasons.

Do your observations hold up as well in a scenario where the password quality checker doesn't over-catch, and thus the user is only told that a password is bad when it really is obviously bad?

(I'm particularly wondering in the context of password manager usage, because zxcvbn basically never turns down a password from a password generator, given that they are inherently random.)

Yes. More-so, 'over-catching' and 'obviously bad' have a countless number of definitions to different developers and users. For some users all password rules are arbitrary, especially as the industry and user expectations move towards biometric authentication.

The reality is this proposal should support the Matrix ecosystem, with whatever password policies & UX Matrix developers want to implement for their users. Intentions and use cases could vary wildly, and in at least one client (Riot Web) we have a requirement to display some password requirements up front.

[babolivier]

I've incorporated most of the review comments minus one about which I have expressed a question here.

[turt2live]

Note that this is already a thing in the spec

.. WARNING::
  Clients SHOULD enforce that the password provided is suitably complex. The
  password SHOULD include a lower-case letter, an upper-case letter, a number
  and a symbol and be at a minimum 8 characters in length. Servers MAY reject
  weak passwords with an error code ``M_WEAK_PASSWORD``.

[uhoreg]

Maybe instead of adding new error codes, we can just stick with M_WEAK_PASSWORD as the error code, and add a new field (say, reason?) to the response that describes why the password is too week. We could make this field an array, so that it can return multiple reasons (e.g. password is too short and has no symbol)

[turt2live]

After some of the discussion in #matrix-spec, I'm inclined to agree. It's likely that we won't have a single error code to point to, and will need an array. M_WEAK_PASSWORD with a reasons array does make sense.

[lampholder]

I'm starting to think that this might not be worth speccing now.

It's true that server side password complexity is likely to be a desirable feature. However, if I understand correctly, it is fundamental incompatible with our desired direction cryptographic authentication (in which the server has no visibility on passwords), so we might be best off special-casing solutions for now and thinking about how crypto-auth and (likely corporate) password complexity policies can live together at a later date.

What do people think?

[grinapo]

All people who still believe the 2003 Curse of Bill Burr (advising using a password hard for humans and easy for computers) shall familiarise themselves with NIST Special Publication 800-63B, especially section 5.1.1, 5.1.1.2 which describe what good and bad practices are there, and what ought to be followed and what avoided.

Basically minimum_length is great. All other fixed checks are bad practices.
Other good practices include the mentioned zxcvbn (and similar pssword strength indicators) along with forbidden words and patterns (common dictionary words etc.), telling the user the requirements and reasons of failure, among other things, I don't want to repeat or summarize the 800-63B unless requested.

It is not forbidden to implement bad practices but they clearly shall be labeled as such.

[babolivier]

This proposal has bitrotten for a while now, and it seems clear that it isn't the correct way to fix this problem. Moreover, I am not likely to be caring after it any more, so I'm closing it.

[ptman]

The server caring about password policies should probably be the OpenIDC identity provider. https://areweoidcyet.com/