Mattermost-server: Password limit on Open Source version is too low

[realrolfje]

In the config.json file, the minimum user password length is 5, and the system does not require upper/lower case letters, numbers or special characters. There is no way in the UI to change this, so I changed the config.js file. To my surprise, the system did not enforce my new password requirement settings.

I understand that there must be an incentive to upgrade to Enterprise for companies. But that does not mean that community members deserve lower security standards.

Please make Mattermost enforce changed password security settings in config.js so we can at least enforce safer passwords for everyone.

[jasonblais]

Thanks @realrolfje! I've queued this for our upcoming meeting to discuss, will follow back

[funkyfuture]

just stumbled across that default and was quiet shocked.

the system does not require upper/lower case letters, numbers or special characters

afaict it's common sense that such idiosyncrasies don't make anything safer, but just make it more difficult for users to remember a password. i suggest to increase the minimum length to 12.

[realrolfje]

It is not about the idiosynchronies. It's about having an insecure default setting, and worse: not honoring the security settings when changed.

Diffences between Enterprise and Free versions should not be in the security of any product. Security is universally important for all people.

[funkyfuture]

my point is, that a password with weird characters isn't safer than one without.

[realrolfje]

I tend to agree, but that is a different discussion alltogether. That choice is up to the user. The real problem is that the system does not honor securty settings, and does not warn about that. Setting the min pasword length to 100 still means that users can have passwords of 10 characters.

[it33]

@realrolfje, @funkyfuture highly appreciate your feedback, some thoughts and a request for your help:

1) What is the correct criteria for a strong password?

There should be some criteria for what makes a strong password. There's a feature proposal and ticket to add a password strength indicator to Team Edition as a start. Until we have a criteria, we can't add the feature.

@realrolfje, @funkyfuture, would you be open to discussing the feature proposal so we can have someone from the community add this?

My ask to you is agreement on how to classify strong and weak passwords, ideally with libraries we can use to implement the password strength indicator in Team Edition. I believe you can help enable this feature if you choose to. Could we have your help?

2) What is the correct way to ensure strong passwords?

The Enterprise Edition options are to enforce corporate policy, but--as you are pointing out--their ability to create strong passwords depends entirely on those policy settings. Having a password strength indicator is more likely to help users select strong passwords than a bunch of error messages.

Enterprise feature are about IT policy, see Manifesto for more on the principles of the open source project.

3) Propose moving this discussion to feature proposal forum

Per community guidelines feature discussions should go to feature proposal forum, and GitHub Issues are for bug reports. The documentation matches the functionality we can't really say it's a defect. Closing this so we can move to feature proposal.

[realrolfje]

I would be happy to discuss what strong passwords are, but closing this issue is ignoring the fact that:

To my surprise, the system did not enforce my new password requirement settings.

That is a bug I'd like to see fixed before we start a lengthy discussion on what strong passwords are. Please reopen and fix. People deserve honesty and security.

This is about Open Source Ethics. A 5 character password is not ethical. Giving false sense of security by silently ignoring safety settings is not ethical. Hiding behind a manifesto nobody reads before installation is not ethical.

I'm very pro open source, and I happily spend my free time helping your awesome team to make Mattermost a great product. But as said before: I understand that there must be an incentive to upgrade to Enterprise for companies. But that does not mean that community members deserve lower security standards.

[it33]

@realrolfje appreciate the feedback,

1) You're right, it's not okay for the setup of Mattermost to be surprising.

I looked into this more, and while our documentation lists out which config.json parameters apply to which feature, if you're trying to infer what things do based on naming, it's not clear, and we should do a better job there.

I've opened a ticket to address this and proposed opening a Help Wanted ticket for the community to contribute this change: https://mattermost.atlassian.net/browse/PLT-6400

We have a design principle of fast, obvious, forgiving.

You're 100% correct that the current design is not obvious, and that breaks our requirement.

Thanks for reporting this.

2) Code Defect vs. User Experience Defect

This conversation brings up a point on how our systems define bugs (code defects) and improvements (user experience defects, small and large features, etc.), which we have defined among core committers, but not made public, so I've opened a ticket to document this: https://github.com/mattermost/docs/issues/1126

3) Enabling strong passwords

I think you're correct that the policy features for passwords don't necessarily create strong passwords.

If you'd like to help enable the implementation of a detector of strong and weak password in our open source edition, there's an existing ticket to help do this: https://mattermost.atlassian.net/browse/PLT-3378

[realrolfje]

Our Mattermost installation is public facing and has a broad range of users (internet savvy to less experienced networkers). The very least I want to be able to do is choose a reasonable password length, so that would be the quick fix in the next fix release in the code, not in the documentation (because of security implications).

The Strong password detector is of course much better, but more of a feature. I'll check issue PLT-3378 and see how I can contribute to that.

[realrolfje]

I just checked PLT-6400 and am shocked. You actually "fix" a security issue by creating an issue to add a link to the documentation, and then even have the balls to ask for community support to add that link? Adding the link in the code directly would have been less work! This makes no sense.

I will not contribute to the strong password detector until this issue is fixed in the code.

As mentioned above, the very least I want to be able to do is choose a reasonable password length, so that would be the quick fix in the next fix release in the code, not in the documentation (because of security implications).

[it33]

Hi @realrolfje, some thoughts below:

On process:

1. If you want to continue the discussion about Mattermost, that is absolutely welcome so long as the conversation is respectful and constructive. If you feel something can be done better, please say so in a way that doesn't belittle other people's implementations or opinions. If you were sitting in the living room of any of the hundreds of contributors who have invested in this open source project, what tone would you use?
2. We've already shared our community guidelines with you previously, I'd ask your help to act as an informed member of the community. I'd ask you to close the dupe ticket. If you're looking for a different design, please consider opening a feature proposal and having it upvoted and discussed publicly--at a minimum, you should have people in your organization vote with you. Over a hundred feature proposals are now existing product features. We have a process that works.
3. If you want to discuss with me or others closer to real time, you can join our community Mattermost server at https://pre-release.mattermost.com/. We have video calling now, I don't mind jumping on. Otherwise, please give time for others in the community to reflect on your comments and respond over time.

On the discussion:

We're transparent that Mattermost Team Edition is "modern communication behind your firewall". It's designed to be self-hosted in a private cloud. If you're putting users on the system that you don't trust, and you don't train them in security, how do you avoid them re-using their passwords in unsafe SaaS services? How do you avoid them sharing passwords over Skype?

Mattermost Team Edition is self-hosted, and therefore designed for trusted users--and that's why we're asking the community to help with a password strength indicator, to help users make the right decision themselves. Enforcement of behavior on users--restricting permissions, requiring compliance with policies, etc.--are enterprise features.

If you're an open source project or non-profit, or in education, there's heavy discounts on the enterprise edition to restrict user choice.

[realrolfje]

Hi @it33,

On Process:

1. I am very sorry if you were offended by the comment above. As you have seen in my other tickets in all systems I am generally polite, focussed on the facts without beig judgemental. In this case I was truly shocked (and still am).
2. I've read the guidelines and am still very convinced that not enforcing even basic security settings is a bug, and not a feature. Furthermore, there are enough issues and comments on this matter.
3. I have accounts on many of your systems. I have a dayjob. I'll consider also joining the community chat but I can't promise anything.

On the discussion:

You may be transparent in the documentation, but the community server you refer to in bullet 3 is very public facing, and rightly so. In your installation, you have the same challenges as I have, which is: collaborating with people you don't even know. Our installation of Mattermost is as secure as we can make it, with seperate webserver and lets-encrypt certificates.

As I've said before, I understand the need to make money and understand the model chosen to do so, but basic security is a basic human right in my opinion. I'm not talking about fancy stuff, but a 5 character password is not my definition of basic safety, it wouldn't even be acceptable inside our companies internal network.

I don't mean to offend people or be unreasonable, but I would have a talk with my boss if I implemented a 5 character password and settings which would not be inforced, and then "fix" it by pointing to documentation. Surely there must be a more elegant solution, one that is more fitting to a product with the quality and community Mattermost has.

[it33]

Hi @realrolfje, again, thank you for bringing this up and engaging in a dialog. Thank you for being a Mattermost user, and thank you for your authentic desire to improve the software. I'm 100% sure you have the best intentions.

Regarding the definition of "bug", I've proposed an update to the issue template to make this more clear: https://github.com/mattermost/platform/pull/6463/files

While different opinions on feature priority are welcome and helpful, I think we need a shared terminology as a starting point.

On the discussion:

1. If you're running a non-profit club of 300 people and need to enforce a bunch of organizational policies, I think you should just request a non-profit license for Enterprise Edition. "Team Edition" is for teams. 300 people, as you've described them in other threads, doesn't sound like a team to me.

2. I agree the implementation of this issue does not solve the stated problem.

There are a set of challenges that need to be solved: a) weak credentials, b) credential re-use, c) credential sharing, d) poor credential storage. In my mind, the proper solution is to insist that people use a unique, randomly generated string from a password manager.

How can we increase the education of users to solve all of a, b, c, and d?

[realrolfje]

I checked your updates to the template. I understand the intention, and I agree with the definition of "bug" in the sense that something doesn't work as programmed, but my personal definition of "bug" also includes ethics. If a program is designed or programmed in a way which is (unintentionally) "unethical" or unsafe, it is a bug too. To me, this is an "obvious error", as mentioned in your bug filing text. I think this is where we disagree.

I see that the Mattermost definition of "Team" is "in a single physical room". In practice this is rare, most Teams needing a chat solution are not in a single room, that's where my expectations mismatch that of Mattermost's definition of "Team".

The password discussion is a complicated one. As a person who uses public/private keys for authentication, a password manager, PGP, I share your worries about re-use, sharing and storage, but that is basically saying the lock is insecure because people give the keys to the neighbour.

Besides the education you metion, challenge b, c and d are outside software control, can never be solved by Mattermost, and not even completely solved with 2 factor authentication. But we can make a good lock, option a, so people at least have a chance to do the right thing.

Regardless discussions of patterns, special characters, and pros and cons of expiration, I am sure we agree that a password of minimum 5 characters can not be considered safe by any definition. Although I'd like to do more, the Mattermost Team must agree with me that the minimum password length setting should be enforced at least.

For example, in our internal company network, a 5 character password is considered unsafe, and as such, I can't even install Mattermost for a demo here. Even with all special characters, a 5 character password can always be cracked in less than 4 seconds. Increasing that to 10 characters immediately increases the guessing time to more than a year.

I hope you can use this information to convince sales people that selling a product where the default password policy makes installing a demo impossible and makes passwords available to any script kiddie in less than 4 seconds is not a good sales pitch ;-)

(sorry for the long reply)

[it33]

@realrolfje hope you've been well. I'm not sure if you're watching our changelogs but over a year ago we added password criteria to the Team Edition: https://docs.mattermost.com/administration/config-settings.html#password-requirements

The commercial Mattermost Enterprise Edition is designed for system admins and the open source Mattermost Team Edition is designed for end users (often developers), and the initial thinking (above) was hard password requirements was a priority for system admins and hence belonged in Enterprise Edition.

I don't remember all the details from over a year ago on this change, but I recall at least two points on why things changed to Team Edition:

1. Better end user experience - When a Mattermost instance was upgraded from Team Edition to Enterprise Edition if a password complexity policy was enforced at the time of upgrade it could require password reset from all the end users, which could be an awkward experience

2. Potential confusion on packaging was minimal - Many customers were buying Enterprise Edition for SSO, so the username/password login requirements weren't super relevant to most system admins considering Enterprise Edition, and so we could have potentially a better end user experience on upgrade without adding significantly to confusion in the packaging.

I'd like to thank you again for the extended discussion on this choice, and sharing your views. I'm glad we were able to iterate over time, and through further analysis to the same conclusion, though for different reasons.