Password requirements are unclear to users

[turt2live]

Many people over the last few days have been tripped up by it not providing helpful information like which symbols/characters to use, length, etc

[turt2live]

and in one case, we lost a user because of it: https://matrix.to/#/!QtykxKocfZaZOUrTwp:matrix.org/$15582451283219566UnUMX:matrix.org?via=matrix.org&via=half-shot.uk&via=linuxgaming.life

[hackers-terabit]

NIST guidelines are now discouraging complex password requirements: https://pages.nist.gov/800-63-3/sp800-63b.html

It would be great if passwords greater than a certain length(12?) are subject to minimal complexity requirements (such as character repetition and keyboard patterns).

This should probably be a feature request on it's own,but, a password blacklist check would also be ideal, maybe HIBP check using a bloom filter (https://github.com/daedalus/bloomHIBP ?)

[jryans]

We have already reduced the zxcvbn requirement from 4 to 3 for the password. I am not sure we can tweak too much more in the current approach, so we'll need a product decision here.

[turt2live]

for some reason it didn't occur to me until now, but matrix-org/matrix-spec-proposals#2000 might fix a lot of the UX issues here...

[lampholder]

I'd love to do some usability testing on the registration, because I'm baffled as to why people are getting stuck on the current flow.

The worst case I've found is if you very quickly enter a common password the feedback is limited to 'this is a very common password' (without a suggestion as to what you should do to make it less common).

As best I understand it, our current implementation is largely in the spirit of the NIST guidelines, is pretty user friendly, and encourages strong password use. The worst accusation I've heard is that in cases where you don't care about the password complexity - where you're making a throw away account to test registration for example - the requirements are annoying. But this is certainly not a use case we should be optimising for.

[lampholder]

As to the user we lost, their question was:

Two responses to this:

• matrix.org doesn't have password requirements - riot web does (i.e. they're enforced client side, not server side)
• is the problem just that the requirements are not documented rather than bad? i.e. would it have been mitigaged if the tooltip said some words about helping you come up with a complex password (by checking your submission for a range of common factors that make passwords guessable, perhaps somehow linking to more information on the topic or the good properties of zxcvbn)?

[emiliogon]

• is the problem just that the requirements are not documented rather than bad? i.e. would it have been mitigaged if the tooltip said some words about helping you come up with a complex password (by checking your submission for a range of common factors that make passwords guessable, perhaps somehow linking to more information on the topic or the good properties of zxcvbn)?

Mainly, that they're not documented. This is a bafflingly opaque and annoying password creation form. If I enter a mid-security password that many sites would accept (any bank I've used), Riot's form error reports "Add another word or two. Uncommon words are better." Yet, adding one character - not a "word" - satisfies the requirement. A couple months ago, I went to try Riot and quit because I didn't know what the password requirements were and it wasn't worth my time to discover them. (I only return now because I need help in an organization's channel.)

But, they're also bad requirements. A 9-character password may mathematically increase security, but do atypical requirements actually produce more effective passwords? I'll always argue for easier UX, especially on a non-critical service. The most effective security measures are always server-side.

This also raises another question: why doesn't Matrix have password requirements. Admins should be able to set password requirements suitable to their server's needs, and the protocol should communicate that to clients to enforce. This shouldn't be Riot's responsibility.

[pheaver]

This is a really poor design decision.

I run a private matrix server with just a few accounts for friends and family members. Nobody is going to be able to do any damage if they get ahold of someone's account. There's no justification for strong password requirements in my use case.

First of all, a frontend client should never enforce password requirements, unless they match the backend and are only being checked in the frontend for performance (so we don't have to hit the backend).

The fact that these password requirements are hardcoded, not documented, very strict, and unchangeable is totally unacceptable. Anyone can bypass them by just using the riot android app -- how absurd is that?

At the very least, can you document how to configure or disable the password restrictions? I've been digging through the code trying to figure this out, with no success yet.

[t3chguy]

It is what is suggested by the Matrix Spec: https://matrix.org/docs/spec/client_server/r0.6.0#notes-on-password-management
@pheaver what you desire is matrix-org/matrix-spec-proposals#2000

[pheaver]

No, I don't desire server side password policies. I desire the ability to configure the client side password policy. As far as I can tell, I'm going to have to build riot-web myself to get that, which obviously is ridiculous.

[t3chguy]

Well people are free to use various riot instances/other matrix clients so you as a matrix server operator wanting control then you need to be able to tell any client what your policy is, which is what MSC2000 is. It adds a route for clients to fetch the matrix server's policy and then they can apply it locally.

[Kiwimaster]

Is there any way to remove the requirement for strong passwords?
Not only is it confusing to members, it creates a support nightmare for us as member constantly forget their password. Also, other clients including Riotx and Riot.im mobile clients do NOT require a strong password.
No good reason to make the web client restrictive if you can bypass it simply by choosing a different client.

[samwilson]

For anyone else coming here wondering what the password requirements are, they seem to be:

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.

(I know @t3chguy linked this above, but it seems worth including here for easier reference.)

[t3chguy]

Closing in favour of #21986