Skip to content

MSC2000: Server-side password policies #2000

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wants to merge 9 commits into from
Closed

MSC2000: Server-side password policies #2000

Changes from all commits
Commits
Show all changes
9 commits
Select commit Hold shift + click to select a range
44fcd1b
Proposal for server-side password policies
babolivier May 15, 2019
2135dd2
Incorporate opinions
babolivier May 15, 2019
3adfe53
Wording
babolivier May 15, 2019
187b06f
Update proposals/2000-password-policies.md
babolivier May 15, 2019
f92f4d8
Update proposals/2000-password-policies.md
babolivier May 15, 2019
2a0b169
Incorporate review
babolivier May 17, 2019
3d2fe12
Remove redundant error codes
babolivier May 20, 2019
34e5547
Typo
babolivier May 20, 2019
a51a057
Don't use plural if min is 1
babolivier May 20, 2019
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
72 changes: 72 additions & 0 deletions proposals/2000-password-policies.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,72 @@
# MSC 2000: Proposal for server-side password policies

Some server administrators may want to ensure their users use passwords that
comply with a given policy. This is specifically relevant to companies and big
organisations which usually want to be able to apply a standardised password
policy across all services.

This proposal aims to define a way for servers to enforce a configurable
password policy and for clients to be aware of it so they can provide users with
an appropriate UX.

## Proposal

This proposal adds a new route, `GET /_matrix/client/r0/password_policy`,
which would return the following response with a 200 status code:

```json
{
"policy": {
// Policy parameter
}
}
```

Five optional policy parameters are also specified:

* `m.minimum_length` (integer): Minimum accepted length for a password.
* `m.require_digit` (boolean): Wether the password must contain at least one
digit.
* `m.require_symbol` (boolean): Wether the password must contain at least one
symbol.
* `m.require_lowercase` (boolean): Wether the password must contain at least one
lowercase letter.
* `m.require_uppercase` (boolean): Wether the password must contain at least one
uppercase letter.

Implementations are free to add their own policy parameters in their own
namespace. This allows server administrators to rely on a custom solution, for
example Dropbox's [zxcvbn](https://github.com/dropbox/zxcvbn) tool which could
lead to a `org.example.complexity` parameter describing the minimum expected
complexity score from zxcvbn's analysis.

Finally, this proposal changes the following routes:

* `POST /_matrix/client/r0/register`
* `POST /_matrix/client/r0/account/password`

By adding new error codes to the list of possible ones returned with a 400
status code:

* `M_PASSWORD_TOO_SHORT`: the provided password's length is shorter than the
minimum length required by the server.
* `M_PASSWORD_NO_DIGIT`: the password doesn't contain any digit but the server
requires at least one.
* `M_PASSWORD_NO_UPPERCASE`: the password doesn't contain any uppercase letter
but the server requires at least one.
* `M_PASSWORD_NO_LOWERCASE`: the password doesn't contain any lowercase letter
but the server requires at least one.
* `M_PASSWORD_NO_SYMBOL`: the password doesn't contain any symbol but the
server requires at least one.
* `M_PASSWORD_IN_DICTIONARY`: the password was found in a dictionary, and is
not acceptable.
* `M_WEAK_PASSWORD` if the reason the password has been refused doesn't fall
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

into one of the previous categories.

## Tradeoffs

A less flexible way to define a password policy (e.g. limiting a policy's
definition to the params for `m.default_policy`) would have been simpler,
however some clients are already implementing their own passowrd complexity
policy (Riot Web, for example, uses zxcvbn), and this solution would improve the
compatibility of the proposed solution with existing software.