Rocket.Chat 🚀 - [Regression] Admin cannot set password for user

Same problem here running on Docker containers with Kubernetes

JASG94 on 29 Nov 2019

Same problem!

cygnusm on 2 Dec 2019

Hi!

this change was intended to limit the admin having access to passwords so that passwords are secrets only known to the user himself.

To change/reset the password of an old user, you can go in the user administration for that user and toggle both "set random password" and "require password change", click "save". The user will receive an email with a temporary password and can then set his new password. This works as well for new users.

Sending passwords by mail will also be soon replaced by a new feature called "invite links".

I hope this solution helps you and you understand our motivation behind this change.

makibras on 4 Dec 2019

👎8 👍2

I think for human users this works ok. But when creating/editing a bot user this isn't so practical. It also conflicts with the instructions on this: https://rocket.chat/docs/bots/create-and-run-a-bot/

wemu on 4 Dec 2019

👍5

@makibras Thanks for opening up this a bit. I now understand the logic, but like @wemu mentioned, it does make creating bots and accounts for troubleshooting purposes bit too complex. Exactly the case where I stumbled upon it.

Our company process for creating routed (working) email accounts is time consuming process to begin with. So now to create a temporary test account I need to assign my own home email account to it (my company one already being reserved for the existing user in rocket.chat).

Gummikavalier on 5 Dec 2019

Technically, a bot user is the same as any other user and needs an email address, therefore can use the same process. This might change in the future. For now, I will close this.

makibras on 6 Dec 2019

@makibras I'm sorry but I have to disagree on this. The a bot user is more of a technical user that does not follow the same password policies as human users. In our case we authenticate users using the oauth features of rocket.chat - I could create the bot user in the forum (our main user source) but the password does not propagate. And after all the user is only required to exist in chat. And its settings/passwords are stored in configs for the bot software. This is nothing like any other user.

wemu on 6 Dec 2019

I read again my answer and it was a bit ambiguous. What I meant to say was that right now, the bot is treated technically like any other user in Rocket.Chat. It is simply a role you can add or remove. As a result, the bot user needs an email and follows the same password workflows.
In the future, we plan to differentiate out the bot user to fit in more of the technical user role, which will probably result in a different way to manage passwords for it, as a bot generally does not have privacy needs.
@wemu: are you blocked right now in setting the passwords for your bots?

makibras on 6 Dec 2019

👍3

Ah I see. Well, yes: in the role point of view I can follow now.

Blocked only sort of. I have an existing bot user, I tried adding another one to test the other bot variations possible with rocket.chat - but I can't create a bot user anymore. But there is no urgent need to do so for me, I can wait - not sure about others though.

wemu on 6 Dec 2019

I'm dealing with the same problem @wemu told.

I understand the new password policy implemented for "normal" users, but, imho it would be great that admins can manage bot passwords, because with this new way of administrate them it's a little bit tricky to create temporaly bots for testing purposses.

JASG94 on 10 Dec 2019

@makibras

this change was intended to limit the admin having access to passwords so that passwords are secrets only known to the user himself.

I'm afraid I don't agree with this policy. You are dumbing down the admin role.

I have a system that uses a dummy domain and the users are unable to use email links.

I set them up with an account and they login JUST with their username and password - no email addresses are used.

And if I am admin and it is my system why CAN'T I reset a users password? It is MY system.

You are basically say I have no control over parts of my own system. I don't have this problem with any other server I run.

I suggest this should be re-opened and the policy rethought.

reetp on 11 Dec 2019

👍9 ❤1

@reetp

Thank you for your comment. The user password is not part of something the
admin should ever know about and common practice. That kind of knowledge
does not belong to an admin. The password is a secret only known by the
user. The admin still has the power to trigger the reset so in your system
you are still capable to do that if you would use regular emails. As you
are using dummy emails, this is quite uncommon so we could try to figure
out a workaround for you. But in general, you need a place outside the
system where the user can receive his credentials. What would the options
for you?

We are working on a way to differentiate the reset out for technical user
roles like bots.

On Wed, Dec 11, 2019, 05:09 John Crisp notifications@github.com wrote:

@makibras https://github.com/makibras

this change was intended to limit the admin having access to passwords so
that passwords are secrets only known to the user himself.

I'm afraid I don't agree with this policy. You are dumbing down the admin
role.

I have a system that uses a dummy domain and the users are unable to use
email links.

I set them up with an account and they login JUST with their username and
password - no email addresses are used.

And if I am admin and it is my system why CAN'T I reset a users password?
It is MY system.

You are basically say I have no control over parts of my own system. I
don't have this problem with any other server I run.

I suggest this should be re-opened and the policy rethought.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/RocketChat/Rocket.Chat/issues/15880?email_source=notifications&email_token=ALSYGMS3JNXQDOGVXOXKQCTQYDC7XA5CNFSM4JS3MLE2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEGSXU2Q#issuecomment-564492906,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ALSYGMQTWCW4ZBLMPYQLRVDQYDC7XANCNFSM4JS3MLEQ
.

makibras on 11 Dec 2019

The user password is not part of something the admin should ever know about and common practice

In a word "nonsense".

On all my servers I can do whatever I as the admin want. (my users have zero control over any of their passwords becuase they are users and will most likely pick useless ones).

I can change their password to one of MY choosing in LDAP that they would have to use in Rocket - so what's the difference setting one in Rocket itself? Nothing whatsoever. This is just "security" paranoia gone mad.

In particular the scenarios where you have either no email address, dummy email address, users ignoring Junk, or email failure have not been considered.

And the greatest irony of all:

@engelgabriel Rocket.Chat is meant to obviate the need for email, and yet ironically you have painted yourself into a corner whereby email use is forced on users.

That just rounds it off nicely.

reetp on 11 Dec 2019

👍8 ❤1 👎1

I'd like to specifically mention that admins are still capable of resetting user passwords directly in the rocketchat database.

They are encrypted, but you can generate one known to you by resetting your own password, and then simply copy it over to any other account. Cumbersome but possible. And of course this method requires access to command line on the server.

Admittedly the current limitation does protect users from any potentially malicious admin role owners that do not have direct access to the database, so I cannot fault the logic completely.

Gummikavalier on 11 Dec 2019

Please document a process if i want to put the password by myself i do not have and do not want enable mail for each password action . Process for admin user to access command line and put password, and think in the future another functionality without using email.

villadalmine on 11 Dec 2019

👍2

I think another workaround might be using the rest api: https://rocket.chat/docs/developer-guides/rest-api/users/create/ - it seems everything is there. Have not tried that yet.

wemu on 11 Dec 2019

@reetp
please keep your comments civil and focused on the issue at the discussion. Selectively quoting me or Gabriel does not help here and from your answer I could not make out a way to help your situation.

It is common standard nowadays that almost all IT systems rely on an external factor in the control of the user (e.g. mailbox, phone) to authenticate him or as a fallback option to receive new authentication credentials. I do not agree with the position that the admin has a right to know everything. Admin work should still be doable without knowing a user password and except for the bot user (which we will change the reset process for), I have yet to see a case where this knowledge is truly necessary. The industry has moved away from letting admins know plain text passwords as these were classic entry doors for easy malicious impersonation.

The problems you mentioned:

users picking useless passwords: we have a password policy that you can enforce in Rocket.Chat to prevent that
no email: in our user creation, we mention that a user needs an email (or use external an identity provider)
dummy email addresses: we do not recommend doing that. If there is a reference to that somewhere, please let me know and I will update it to the new policy.
users ignoring junk mail: In the particular case we are talking about, either a new user needs his PW , an existing user has requested a reset or the admin forces a reset: you can safely expect the user to monitor his email address for that password notification or, in case you as admin force the reset, should make that known to the user via a secure side channel.
email failure usually comes in two situations: misconfigurations or email server down. The first one should result in troubleshooting, we have our support channel in open to help with that. When email server is down, how rare this might be, yes, that could be a problem. I dont have a solution for that right now. Maybe we could add the option of a fallback server in the admin settings, if there is a demand for that. But in general: availability of third party systems is not something in control of the Rocket.Chat application. The same argument could be said, that the OAuth provider is down. That is a general IT risk and there is no 100% guaranteed uptime.
Your reference to LDAP is correct, but external system security is not in our control. Personally, I would not recommend an LDAP system where the admin can modify user passwords without compensating controls in place, but this is not my point here and external LDAP policies not for me to decide.

To sum up, I do not see this as paranoia but a step in the right direction.

@wemu
yes, the rest API is currently possible. A heads up though: we are planning to close that path as well, but leave it open for bot users. This should be helpful for your case, so you could manage your bot users via the API.

makibras on 12 Dec 2019

👍3 👎1

please keep your comments civil and focused on the issue at the discussion

I was. You should see me when I _am_ being rude. Just because I disagree does not make me rude.

do not agree with the position that the admin has a right to know everything.

We'll have to agree to differ.

It is my system, and surely it is up to me what happens? I can do whatever else I want on my server. I know everything else that goes on with it, because legally I have too. Why should Rocket be any different?

As already pointed out, it is still perfectly possible to change passwords in the DB, so your change really accomplishes nothing beyond making life difficult for sysadmins. It doesn't actually fix anything. So it is just paranoia in a paranoid world where no one takes responsibility for anything and just want someone else to blame.

It is narrow thinking to believe that Rocket admins have no access to their local DB, and disabling the password reset prevents them from changing it. That may be true on big systems, but Rocket has a vast base of small systems so it totally ignores lots who do have such access, including me.

Maybe I just want to reset a password for them to subsequently change with a force reset.

Maybe I have my own password policy I prefer to use. But these are my choices that you are removing.

Perhaps a Superadmin role with access all areas is something that should be considered. Logically it makes more sense.

Emails.

Dummy emails - we do not recommend doing

But... why not? It works perfectly. Just what I want. And if you are trying to go 'email less' it is perfect. Remove emails altogether......

Junk - you can safely expect

Actually, this is a very poor assumption, and from experience no, I can't expect this. Seen this occur far too many times where users insist at length they have checked, and an email resides in their junk. Or even worse it resides in the admins junk system and they haven't bothered to check and allow mail to pass through to users. I can give you a mountain of examples why email is so bad.

I also have some users on one server that also block ALL HTML mail, so until you allow plain text emails they cannot receive a password reset at all.

So you need to fix this first.

https://github.com/RocketChat/feature-requests/issues/187

Servers - misconfigurations or email server down

Whilst this is not in your control, you cannot insist on its usage,. It is just totally illogical to insist on email for passwords when you can't guarantee that email is working. Your support channel isn't going to fix that is it?

but external system security is not in our control

And that is entirely the point. Emails are not in your control and never will be. So don't remove my ability to set user passwords as I see fit for any reason, be that email failure, Oauth failure, LDAP failure, rejection of HTML mails, or just because I want too.

And yes, I have a strong feeling that you are going to try and remove the whole password setting panel, remove all control of passwords, and rely purely on links in due course. This is just the tip of a completely disastrous iceberg. Of course, I could be wrong. I'm sure you can correct me.

==============

Rocket.Chat (and chat in general) is meant to be disruptive and replacing email.

Forced use of email is unreliable, and also totally breaks the entire raison d'tre of Rocket.Chat

reetp on 12 Dec 2019

👍6 ❤3

please keep your comments civil and focused on the issue at the discussion

I was. You should see me when I _am_ being rude. Just because I disagree does not make me rude.

do not agree with the position that the admin has a right to know everything.

We'll have to agree to differ.

It is my system, and surely it is up to me what happens? I can do whatever else I want on my server. I know everything else that goes on with it, because legally I have too. Why should Rocket be any different?

As already pointed out, it is still perfectly possible to change passwords in the DB, so your change really accomplishes nothing beyond making life difficult for sysadmins. It doesn't actually _fix_ anything. So it is just paranoia in a paranoid world where no one takes responsibility for anything and just want someone else to blame.

It is narrow thinking to believe that Rocket admins have no access to their local DB, and disabling the password reset prevents them from changing it. That may be true on big systems, but Rocket has a vast base of small systems so it totally ignores lots who do have such access, including me.

Maybe I just want to reset a password for them to subsequently change with a force reset.

Maybe I have my own password policy I prefer to use. But these are my choices that you are removing.

Perhaps a Superadmin role with access all areas is something that should be considered. Logically it makes more sense.

Emails.

Dummy emails - we do not recommend doing

But... why not? It works perfectly. Just what I want. And if you are trying to go 'email less' it is perfect. Remove emails altogether......

Junk - you can safely expect

Actually, this is a very poor assumption, and from experience no, I can't expect this. Seen this occur far too many times where users insist at length they have checked, and an email resides in their junk. Or even worse it resides in the admins junk system and they haven't bothered to check and allow mail to pass through to users. I can give you a mountain of examples why email is so bad.

I also have some users on one server that also block ALL HTML mail, so until you allow plain text emails they cannot receive a password reset at all.

So you need to fix this first.

RocketChat/feature-requests#187

Servers - misconfigurations or email server down

Whilst this is not in your control, you cannot insist on its usage,. It is just totally illogical to insist on email for passwords when you can't guarantee that email is working. Your support channel isn't going to fix that is it?

but external system security is not in our control

And that is entirely the point. Emails are not in your control and never will be. So don't remove my ability to set user passwords as I see fit for any reason, be that email failure, Oauth failure, LDAP failure, rejection of HTML mails, or just because I want too.

And yes, I have a strong feeling that you are going to try and remove the whole password setting panel, remove all control of passwords, and rely purely on links in due course. This is just the tip of a completely disastrous iceberg. Of course, I could be wrong. I'm sure you can correct me.

==============

Rocket.Chat (and chat in general) is meant to be disruptive and replacing email.

Forced use of email is unreliable, and also totally breaks the entire raison d'tre of Rocket.Chat

I agree why force to use email ? I have my own server with my own rocket chat for internal use.
All of my. user are admin we are a. group of friends using rocketchat because we do not want
to use other messaging tool , I. think I. do not want to force use email in my server and if i do not want any secure authentication it is my fault i do not want no one push me how do i need to do. with my prefer authentication method. But i respect your final action, it is your project .
I hope will have power to use some method without email, or just i will continuing using cli in DB :)

villadalmine on 12 Dec 2019

yes, the rest API is currently possible. A heads up though: we are planning to close that path as well, but leave it open for bot users. This should be helpful for your case, so you could manage your bot users via the API.

In my opinion it makes no sense to allow the password change through the API but not in the UI in the case of bot accounts.

It's just my opinion, but it makes admin life's difficult unnecessary

JASG94 on 13 Dec 2019

As mentioned before, this change just makes it more complicated to change passwords, but not impossible. I don't understand the change either. I mean, couldn't you just change the email to one you control and reset the password then?

MIKI785 on 13 Dec 2019

Why not making this configurable?

RocketChat has a lot of things configurable. Why not continue in the same "everything configurable" policy?

THIS IS A SUGGESTION..

didacroyo on 15 Dec 2019

👍5

This policy is - imho - severly misguided. I am the admin of my server, and the users are 100% maintained by me. They all use a fake email, and atm I have no way of resetting their password.

Further, the idea that admins should not know the users password is 1. wrong, and 2. could be mitigated by forcing a password change at first login. It should not be be up to the rocket chat developers to protect my users against their admin. If they wanted a 3rd party custodian of their safety, they would use Slack.

Please change this. I now have several users locked out of our server, and I'm getting quite alto of heat for it.

sss-wg2 on 18 Dec 2019

👍8

Hi guys, thanks for your inputs and comments. I understand some of your frustration. Let me add a few comments as a lot of things are thrown together:

What we took away was the option to directly set and view user passwords by admins via the UI. Why? Our policy is: User password values should be known to users only because together with their username/email address, they are their proof of identity. At no point should an admin know both parts (username AND password), which was the case in the old setup as the admin could reset and see it. (knowing the hash in the database does not equal knowing the user password). Admin work can still be performed without knowing user password values and you can still trigger the reset to an external factor. The external factor (e.g. email address or a mobile phone) in control of the user outside the system itself is needed for a user to manage his credentials.

These policies are standard in modern web application behavior and systems that dont follow these policies lack integrity as the user authentication cannot be ensured if the admin can set the password in the system directly and knows the password so it loses its value as proof of identity. The external factor - such as email - has to work of course, so feature requests like providing a way to enable plain text-only emails are valid and good requests that we will give our attention to. All problems mentioned (admin replacing hash in DB, admin changing user email and then reset) are valid but not intended to be addressed by this change. These actions leave traces in the system and the system loses its integrity for this user from this point, allowing the user to repudiate all actions under his account from this point, ergo protecting the user. No change can cover all attack vectors.

The effect of this change is that the dependency on email as the external factor under user control becomes now enforced. In the past, users already needed an email to register. That this mandatory field was filled in some setups with dummy emails was not intended in our design, yet it seemed to have worked in the past. This break is unfortunate for those of you affected and it is not that we wanted to break your system but it enforces our policy of the external factor and therefore prevents setups with dummy emails. Foreseeing all setups of Rocket.Chat is unfortunately not possible for us to know. Please switch to real email addresses or third party authentication (e.g. OAuth). Or (not recommended) you as admin could set up and manage real email addresses for your users as you are seem to be doing a full service for them anyway in your setup already.

What is currently planned upcoming?
For Bots we will enable the admin to set their access tokens directly via the UI (upcoming).
Also there are additional alternatives planned of using the second factor (e.g. push notification, authenticator app) where enabled, so you would not need to rely just on email but the user could use another factor. So the hard reliance on email would go away with this one and probably some of your problems solved, but the reliance on an external factor remains. Forcing the admin using his second factor for profile changes like email is also planned. There will be configurable parts to these ones for you, the exact ones to be defined.

To summarize and for everyone stumbling on this issue later during search: we had to balance a quality of life feature for admins with user security of a system with integrity-requirements and chose the latter because most setups have this integrity requirement. We do not intent to reverse the change, but want to help all for whom this was an actual change breaking their setup and soon then remove the hard dependency on email by allowing additional external factors. Where you see a potential implication of this change that you could see as a potential issue (like the plain text-only email mentioned), please set us know and open a separate issue so we can proactively work on this.

makibras on 19 Dec 2019

Your points are mostly valid, and I tend to agree with them.

However, if the intention is to prevent the admin from knowing the plain text password, this can be achieved by allowing the admin to set a one time password (or even generating one), clearing all sessions for the users in question, and forcing a pw change at first login.

What you are really achieving by this change is simply to force the use of email or sms as a way of communicating passwords. I would like to be in control over which out of band channel I use to communicate my users passwords.

You are doing great work with Rocket Chat, but this change is a step in the wrong direction. You are basically trying to limit what admins can do, which is completely futile unless you run a service.
It does not add any real security, only more obscurity, nor does it enhance the "integrity of the application" (whatever that means).

This gives a fake sense of security and adds allot of hassle for both users and admins.

sss-wg2 on 19 Dec 2019

👍10 ❤2

We do not intent to reverse the change

Oh, thanks a lot then.

but want to help all for whom this was an actual change breaking their setup

See below. Why haven't you fixed plain text emails yet?

soon then remove the hard dependency on email by allowing additional external factors.

It's a bit late for that isn't it? You have already created it. That has meant some people can't upgrade because they don't use email. The whole point of Rocket.Chat. Replace email. Not depend on it.

On your own website (I notice you censored my previous post pointing out this fact):
https://rocket/chat

"Open Source Team Communication
Rocket.Chat is free, unlimited and open source. Replace email, HipChat & Slack with the ultimate team chat software solution."

I'd like to know how you intend to 'replace' it? What other 'factors'? Why go through all this?

Where you see a potential implication of this change that you could see as a potential issue (like the plain text-only email mentioned), please set us know and open a separate issue so we can proactively work on this.

Done that. Nothing so far.

This was opened 12th September long before this disastrous and unnecessary change was mooted and never had any acknowledgement by developers. Just ignored as usual. So anyone that rejects html mails can't get a password change.

https://github.com/RocketChat/feature-requests/issues/187

This change still breaks any server where the user cannot receive an email. It does absolutely nothing for the security of the server (an admin can still hack the database, and it doesn't stop admins setting passwords in backend password management systems eg LDAP etc)

It is just a irritant to a system administrator. Nothing more.

NB - emails are still readable which breaks your security model in any event. As server admin I can just copy any emails to wherever I want and read at my leisure.

If you intend to use some form of 'link' you are just increasing the dependency on email. Some of us have users that will not use either email or phones linked to a Rocket instance. Not sure how you intend to get around that. I have a private instance, create a user, a password and a dummy email. That's it. So now you have broken that with no fix.

This has been rushed through, badly thought out, and badly implemented with no considerations of the wider implications for many.

Perhaps you imagine 'Administrators' as purely a 'role' within Rocket that have no access to the underlying infrastructure. However, I think an awful lot of admins are the server admins as well. They can do whatever they want, and should be allowed to do so. It is their server after all.

This is just nanny state overkill.

I mentioned before that perhaps you should have a super admin role that CAN control these sorts of factors. It is perfectly normal for an admin to control any data they want.

Next you will be telling me I can't change my users passwords on my own servers.......

:headdesk:

reetp on 20 Dec 2019

👍8

Another workaround.

If you use dummy emails and you are a sysadmin hosting your own instance then just keep some pseudonyms on your mail server and direct all those pseudonyms to your admin account. You can then read them and send them to your users via a secure method. Simples. It will also work if they (insanely) try to implement some form of 'link' as you can open the link yourself, and reset the password fore you user.

Note to developers.

As amply demonstrated, this is just an annoying inconvenience. It does nothing for security.

Note also. I do not want or need user emails or phones to identify users. That is their private information and I do not want to force them to divulge it. I think there may even be some Rocket systems where they don't want to ID users at all in any way - think systems located in areas with more extreme governments.

Holding this sort of data also increases my legal liability, made worse by the fact that Rocket is still not GDPR compliant.....

reetp on 20 Dec 2019

👍5

If I also read this correctly you are going to force 2FA on admins as well?

Forcing the admin using his second factor for profile changes like email is also planned.

Who is actually in charge of their server? Rocket or the administrator? Have you really thought out the consequences of this because your track record to date is not great.

This is a completely retrograde step IMHO. There are many users with air-gapped systems, no external email, no phones etc.

This will break it for many. For what?

Adding security features for admins who want them is one thing.

Forcing them to use said features and removing any form of control is bullyboy tactics by over exuberant security 'experts' trying to tell us how to do our job.

It's actually quite insulting. I was one of Rockets greatest fans, but that fire has gone now.

I understand now why other people have packed their bags and moved on, and why there is so little community at Rocket.

It is always the same when developers just will not listen to users. Just because we are 'only members of the community' and not 'paid staff' does not make us either stupid, or wrong.

reetp on 23 Dec 2019

👍7

This should be a configurable parameter

altapo on 24 Dec 2019

👍7

This is starting to seem like a slippery slope. Forcing these kinds of changes down on those that run their own instance is not preferred. So now I need to setup another service on my rocket instance, just so it can email out password reset links? No offense, but that is just poorly thought out. This change alone will force me to start considering other options for chat.

BTW: Does anyone know the last valid update before this change was pushed, might be time to downgrade.

nahga on 24 Dec 2019

👍1

Umm yeah, can somebody just make a checkbox to turn this off? This is a stupid idea. I put fake emails for ALL MY USER ACCOUNTS. This is a dumb in-house self-hosted server THAT HAS NO MAIL SERVER!!!!

rj11 on 25 Dec 2019

I'm typing it at 1:00AM when SANTA is supposed to be here!!

rj11 on 25 Dec 2019

HOW DOES THE ADMINISTRATOR RESET A PASSWORD???? GIVE ME COPY/PASTE EXAMPLES PLEASE FOR UBUNTU 18.04 AND SNAPS

rj11 on 25 Dec 2019

You can try to test matrix project it is a decentralized chat , looks more interesting and it is really a secured project where the decisions are taken carefully and with best approach , so sad about how changed Rocket chat , those decisions destroy the community edition ... also you can still using version 2.2

villadalmine on 25 Dec 2019

👍1

Hey guys,

I´m gonna reopen this issue and we are inviting you for comments in January after the holidays when our team is back and we had a working session planned on this and future changes.

Merry Christmas

(@rj11: I deleted your swears. Please stop that.)

makibras on 25 Dec 2019

👍6

This ranks right up there with not giving admins access to an easy way to read chat logs between users. I understand that there is somewhat of a security component to this, but your processes and thinking behind this are horrifically misguided.

This is a BASIC feature of any software like this, that needs an administrator. This is a BASIC function of administration. We don't all have the same setup, and you should know and understand that not everyone will have an email server setup for this. I now have no way of creating new users, or changing passwords for users. You REALLY don't understand why this is a big deal??? If you are going to make such drastic changes, you should either be asking admins if this is something they want, or letting us know well in advance, so we aren't scratching our heads wondering where the functionality disappeared to seemingly overnight. I really feel like you should have known to at LEAST leave an option for admins to decide on their own servers how to implement this.

As painful as it will certainly be, I now need to start considering a different option for our chat...This isn't how things should work.

sadkins76 on 26 Dec 2019

As mentioned by many other admins here and in the forums, this change is totally misguided. This issue gives me very little confidence in using Rocket Chat at all. I don't want to be forced to downgrade to get the feature back, so if it is not re-instated early in January I will move to another platform. I am not going to mail-enable all of my users, I am not going to mail-enable the Rocket Chat server at all, because it does not need to.

michelpy on 28 Dec 2019

👍7

I have done some thinking and decided that this is deal breaker for me as well. I do in fact have an email server, and not so many users that working around this "feature" is to much work, but the whole thing just leaves a very bad taste in my mouth.

Drastic changes to such a basic feature should at the very least be clearly marked as deprecated in the UI for a meaningful length of time so that affected admins have time to prepare and adjust. I simply woke up one morning and had suddenly basically lost all control over user management on my instance.

Further, the arguments for the change reveal a worrying lack of knowledge or consideration for what security actually is, and a completely tone deaf approach to running a project where you release your stuff into the wild for other people to use as they see fit.

The first step in any security related problem should be to ask who you are protecting against. If the answer is that you are protecting users from root, the whole thing is a non starter. There will always need to be a omnipotent entity at the top that can do everything, and I suspect that for most of us the whole point of using rocket chat, instead of some service or the other, is that we want or need to be that entity. Forcing us through some arbitrary hoops to get there is just silly and creates annoyed admins.

As I said before: This adds no real security, only very real frustrations. If this is not reverted very soonish in the new year I'll move on to something else. I have to spend time on this mess anyway, and moving to a new system is not that more laborious than having to set up and curate a local loop email setup for my users so I can reset their passwords.

sss-wg2 on 28 Dec 2019

👍2

@sss-wg2 I could not have said it better.
I'm not the only admin of my Rocket Chat instance, actually. My admin assistant and my helpdesk also are, and yes we know user's passwords and yes we log in as them on their PC or on their phones. There are plenty of reasons why we need to know the user's passwords. Geez isn't it enough that a dozen of us have asked for that feature to be put back for it to happen ?

michelpy on 28 Dec 2019

Just give up, these guys will NEVER put the password field back. They will NEVER accept a pull request that puts the password field back. They've made a stupid decision and can't go back now because there is NO WAY TO SAVE FACE. There is absolutely no TECHNICAL reason why you can't just put a checkbox and put things back to the way they were. IT'S POLITICAL.

The only way out now is to fork the code, blah blah, see: openoffice and libreOffice, Xfree86 and X.org, etc. etc. it takes forever and ugh (rolls eyes) here we go again.

bubbapizza on 28 Dec 2019

well maybe we can cook this down a bit? Since the rest api still contains the feature I don't think it was already removed completely and its impossible to re-introduce it until a better handling is found. The feature was removed before a better solution was available. Or an option to provide it via a marketplace exists.

I think the mistake that really happened here is that the relation between the feature and the use-cases it is used in got lost.

So far what I understood and noticed:

people use rocket.chat in air gapped installations. all "send me a password" features are pointless here.
people don't attach rocket.chat to an email server. from here on asking for an email address is pointless. some countries are rather strict on asking for user data that you don't need.
bot or automation users that only exist in rocket.chat

If I missed some I would recommend to state them clearly.

On the other hand there is an aspect of confidentiality - despite the "admin knows everything" approach. This may be valid for some, it may also be not valid for others.
As an admin I want to be able to "fix things" if broken or check things if reported. But I don't want it to be too easy to invade a users privacy without him/her knowing. By changing or setting a password I would suggest sending a message to that user (by both email if available and direct message within the chat). Admins should be able to fix things but not un-noticed. If something like that exists these accounts are quite dangerous for your community - and will be targeted.

So maybe with some thinking and less drama we can achieve both confidentiality and safety for users as well as manageability for administrators and staff.

if it's political and rocket.chat moves into a cloud service focused / very connected software: that would be a shame. I like the self hosted variant and its features. My only wish here would be transparency on that decision. So current users that focus on self-hosting can make theirs.

wemu on 29 Dec 2019

@wemu :

well maybe we can cook this down a bit?

Thanks.

people use rocket.chat in air gapped installations. all "send me a password" features are pointless here.
people don't attach rocket.chat to an email server. From here on asking for an email address is pointless.

Both of these apply, in my case. I don't want to connect it to email, I don't want to connect it to AD/LADP. I could if there was a business need, but there is none. The android devices do not have a SIM, they never leave the premises.

Also, it is not that easy to change a password. 90% of my users wear gloves, typing h3d%9sWJ7!sI on an android keyboard while trying to copy it between two apps while wearing gloves is not productive.

But I don't want it to be too easy to invade a users privacy without him/her knowing. By changing or setting a password I would suggest sending a message to that user (by both email if available and direct message within the chat).

This point is moot. If I change the password, the user will notice because they won't be able to log in anymore, therefore they will know that I have changed the password anyway.

some countries are rather strict on asking for user data that you don't need.

Allow me to try (I am not a lawyer) to explain how it works here in the US. All of my users are employees, so their privacy is rather limited. They have signed a contract. As the admin, I have the technical ability to read their emails and record their phones without them knowing. When I say technical, I mean that having the tools to do so is legal. I also have video cameras all over the place.

Can I spy over employees ? Yes and no. Legally, I can't do it on my own; but if HR asks me to, it is legal. I have been asked several times to provide emails between 2 individuals, or to provide a list of web sites visited by someone. I am the admin, I do not own that data but my company does. It is not a community : the company pay employees to do something per the rules it sets.

When we remote desktop to a workstation, there is a popup that asks for permission, but there are plenty of cases where we need the password, one of the most widely used is that they are not at their workstation and the screen is locked (timeout policy).

So, a lot of stuff comes before my eyes. In 35 years of career, I have seen it all.

And, I actually have seen the Rocket Chats between employees. For the most part, it is "hey frank are you going to be done in 15 minutes and do xyz after it, or should I send bill ?"
This is doubly worthless info : not only the content itself is worthless, but it is already expired by the time I look at it.

Trying to remove the ability to change or set the initial password is a total waste of my time. I have root, I have VM snapshots, I have physical access both to the server and the workstations, for crying out loud if I want to know what a user's password is I will eventually get it.

michelpy on 29 Dec 2019

add html to /app/ui-flextab/client/tabs/userEdit.html

{{#if hasPermission 'edit-other-user-password'}}
++++++++++++++++++++++++++++++++++++++
<div class="rc-form-group rc-form-group--small rc-form-group--inline"> <div class="rc-input rc-form-item-inline"> <label class="rc-input__label"> <div class="rc-input__title">{{_ "Password"}}</div> <div class="rc-input__wrapper"> <div class="rc-input__icon"> {{> icon icon='key' }} </div> <input name="password" class="rc-input__element rc-input__element--small" type="password" id="password" autocomplete="off" value="" disabled="{{requirePasswordChangeDisabled}}"/> </div> </label> </div> </div>
+++++++++++++++++++++++++++++
`

        <div class="rc-form-group rc-form-group--small rc-switch">
            <label class="rc-switch__label" tabindex="-1">
                <input class="rc-switch__input" type="checkbox" id="setRandomPassword" value="1" checked="{{setRandomPassword}}" disabled="{{setRandomPasswordDisabled}}"/>
                <span class="rc-switch__button">
                    <span class="rc-switch__button-inside"></span>
                </span>
                <span class="rc-switch__text">
                    {{_ "Set_random_password"}}
                </span>
            </label>
        </div>
        <div class="rc-form-group rc-form-group--small rc-switch">
            <label class="rc-switch__label" tabindex="-1">
                <input class="rc-switch__input" type="checkbox" id="changePassword" value="1" checked="{{requirePasswordChange}}" disabled="{{requirePasswordChangeDisabled}}"/>
                <span class="rc-switch__button">
                    <span class="rc-switch__button-inside"></span>
                </span>
                <span class="rc-switch__text">
                    {{_ "Require_password_change"}}
                </span>
            </label>
        </div>
        {{/if}}

`
and then build docker imag.

nnluc073 on 30 Dec 2019

I'm only coming into this "bug" now, though I noticed this change recently. I don't see any reason this feature should have been removed. I don't see any security benefits it would give, any functionality benefits, nothing. Please revert this change.

im-strongthany-zz on 31 Dec 2019

👍2

BTW: Does anyone know the last valid update before this change was pushed, might be time to downgrade.

I believe 2.2.1

If you are on a manual or docker install you can stay where you are. Snap users won't have any choice....

The great irony with this is that many of us will stay on 2.2.1 to avoid this change which means that we are running 'insecure' systems because there are now bug fixes we will not apply.

So much for increasing security...........

I still believe there is a case for a 'Super Admin' eg root account which then has control over 'Normal' Admin accounts for setting such as this.

Also for those of you reading this take a look at this as well:

https://github.com/RocketChat/Rocket.Chat/pull/15949

On new installs 2FA via email will be enabled BY DEFAULT.

That is one PR away from making it mandatory, period.

I'll say it once again because no one can answer this yet. How can you live up to the claim on your website front page when you make email a hard dependency?

Replace email, HipChat & Slack with the ultimate team chat software solution.

You cannot replace email if you rely on it for functionality. Either change the policy, or change your website please as it is currently false advertising.

Perhaps someone can ask Gabriel on the next AMA at open.rocket.chat

reetp on 31 Dec 2019

I have not tested this, but it should do the job....

Login to Rocket.Chat
Click on your user Avatar and click "My Account"
Click "Personal Access Tokens"
Give it a name and click "Add"
Copy the information that pops up (token and user id) into a text document so you have it for later.

Linux / Bash Instructions (with curl installed)

Copy the following few code snippets into a notepad and replace the tokens and userid's with your token and user id from step 5.
Replace the "USERNAME_OF_USER_YOU_WANT_TO_CHANGE" in the first code snipit with the username of the user you'd like to edit.
Replace the "REPLACE_WITH_YOUR_SERVER" with your chat server hostname.

curl -H "X-Auth-Token: REPLACE_WITH_YOUR_TOKEN_FROM_STEP_5" \
     -H "X-User-Id: REPLACE_WITH_YOUR_USER_ID_FROM_STEP_5" \ 
     https://REPLACE_WITH_YOUR_SERVER/api/v1/users.info?username=USERNAME_OF_USER_YOU_WANT_TO_CHANGE

Open a terminal and paste the above code snipit with the changes from steps 6-8. It should return a JSON object starting with "user".

Copy the user's ID, it will be the id followed by a "_id".

Example:

 {"user":{"_id":"YGw5gegt45ssoBJd","createdAt":"2018-07-30T20:23:10.675Z","services":{"password":{

The user's id is: YGw5gegt45ssoBJd.

Copy that into your notepad.

Copy the following snipit into your text editor

curl -H "X-Auth-Token: REPLACE_WITH_YOUR_TOKEN_FROM_STEP_5" \
     -H "X-User-Id: REPLACE_WITH_YOUR_USER_ID_FROM_STEP_5" \
     -H "Content-type:application/json" \
     http://REPLACE_WITH_YOUR_SERVER/api/v1/users.update \
     -d '{"userId": "REPLACE_WITH_USER_ID_TO_CHANGE", "data": { "password": "The new password", "requirePasswordChange": true }}'

Replace the required fields. Notice the "password" and the "requirePasswordChange". You can set "requirePasswordChange" to false if you don't want to force a password change on their first login.
Go back to your open terminal and paste in the snipit.
Profit!

EDIT

See https://github.com/RocketChat/Rocket.Chat/issues/15880#issuecomment-569960810 for a functional bash script

wreiske on 31 Dec 2019

Looks as tho downgrading to 2.2.1 is not possible on a manual install if you've already updated to 2.3.1
Still not sure how these developers can think email is the solution for this. In my use case, email does not exist. I have only 12-15 users, and I know none of their email address. That is the way we want it. Our instance is configured as a mirror for an IRC channel so people can access/continue to chat without access to an IRC client. The bot on either side sends all messages in the chat to the remote side. This enables both web and mobile access to the IRC chat.
Now if one of the users forgets his/her password....well game over. I'm not one of those admins who feels I should know the users passwords. I don't want to know their passwords, but I should be able to temporarily reset them. I do understand some of their concerns with admins knowing the passwords of users, so just make it mandatory that users HAVE to change their passwords on the next login if it was set by the admin, done. Why isn't this the solution?

nahga on 31 Dec 2019

Wrote a little bash script to change user's passwords for those that need it.

https://gist.github.com/wreiske/9e3f28900baa6ec82c0ac567e6f920d6

wreiske on 31 Dec 2019

👍5

In case it will be removed from API one can use the direct database method:

Directly check a specific user ID from bash (requires pymongo):
$ mongo rocketchat --eval "db.users.find({'username':'usernamehere'}).forEach( function(u) { print(u._id + \" ; \" + u.username); } )"
 * I did put this here in case one wants to try bash scripting for this

Log into rocketchat database:
$ mongo rocketchat

Check out all the user IDs in the database: 
> db.users.find().forEach( function(u) { print(u._id + ";" + u.username); } ) 

Or just a specific user's ID:
> db.users.find({'username':'usernamehere'}).forEach( function(u) { print(u._id + \" ; \" + u.username); } )

Replace specific user ID's password in the database:
> db.users.update( {'_id': 'useridhere'}, {$set: {'services.password.bcrypt': 'bcryptedpasswordhere'}}, {multi:true} )

My only issue with above (only time I needed it for recovery purposes), was that I didn't know which tool to use to generate a bcrypted password. So in the hurry I copied the hash from one account I already knew (my own). If someone knows a good command for creating one directly in bash, I assume it would do.

For listing out any passwords in the database I used:

>  db.users.find().forEach( function(u) { print(u.services.password.bcrypt + " ; " + u.username); } )

If you are going to test this out, please do backups with mongodump command beforehand.

Gummikavalier on 1 Jan 2020

This for listing doesn't work if you have an 'undefined' user (long story why you might have)

db.users.find().forEach( function(u) { print(u.services.password.bcrypt + " ; " + u.username); } )

However, you can get it for an individual user with:

db.users.find({'username':'SomeUserName'}).forEach( function(u) { print(u.services.password.bcrypt + " ; " + u.username); } )

reetp on 2 Jan 2020

This for listing doesn't work if you have an 'undefined' user (long story why you might have)

db.users.find().forEach( function(u) { print(u.services.password.bcrypt + " ; " + u.username); } )

However, you can get it for an individual user with:

db.users.find({'username':'SomeUserName'}).forEach( function(u) { print(u.services.password.bcrypt + " ; " + u.username); } )

https://forums.meteor.com/t/use-mongo-shell-to-change-user-password/4018/6 may be helpful here.

wreiske on 2 Jan 2020

👍1

Thanks for your comments, let's try to clarify some things here and propose improvements.

Answering some topics

It's still possible to set the user's password via REST API

Yes, we are removing the options step by step, we are going to remove this option soon.

Plain text emails

We are listening to the community, but don't expect a new feature or a fix with just 1 or 2 requests from the community, we hove other requests with more engagement that are prioritized. Since we understood the HTML emails were a problem to receive the passwords we made the pull requests to implement the feature https://github.com/RocketChat/Rocket.Chat/pull/16065 and https://github.com/RocketChat/Rocket.Chat/pull/16063

It's still possible to change the user's email to receive the password.

Yes, as said before, we are doing the changes in steps. It will continue to be possible to change the user's email, but now the user is notified about the change on the old email address and with the Two Factor Pull Request the administrator will need to input the 2FA code or the password to proceed, that will prevent anyone who stole the admin's session token to gain access to other users' accounts.

It's possible to change the password in the database

Yes, it is and will continue to be possible. It's not our intent to protect the database but the system. System administrators will continue to have the power to change any data if they have the user and password of the database. Think as you would like to give the admin role to someone to help you, that's true in lots of installations, this person will not have access to your server, so our enforcement here works.

We are not listening to the community

It's not true, the proof is this thread, we are here trying to find the best fit between the security we want for the product and the flexibility you need. Of course, we can improve the way we introduce those changes, it's clear now that we should present this kind of change to the community upfront. Unfortunately, we didn't prevent use cases where people were using fake email addresses since Rocket.Chat was designed to have emails as required for authentication.

This change seems to be Political

It's not true, it was driven by our security concerns. We understand your frustration, and we will work to mitigate this. Just bear in mind that we are thinking of all of our users where most of them use our system correctly and desire more security.

Two Factor enforcement

The Two Factor Pull Request is not enforcing the use of emails, it's an option that will be enabled by default for new installations and will only work for users who have their emails verified, if you are using a fake email it will not be enabled for you since you didn't use the verification link because you didn't receive that email. But that PR will add a whole new way to start adding more security to our APIs, if the user doesn't have TOTP (google authenticator) configured, don't have the email verified (or disabled the email for 2FA) the password will be required to act. This is important to prevent someone to steal your token and be able to execute sensitive changes. Please visit the pull request and check all the items implemented there.

Super admins

We've discussed the possibility to have super admins, it can be implemented in the future, but it would not solve the security issues if someone steals the super admin's token. XSS is hard to prevent, unfortunately, but we can reduce the damage caused by a stolen token.

A proposal

We understand this change has been frustrating for a considerable number of users. I'd like to apologies for the way this change landed, but we don't want to just bring the password field back, it would be a step in the wrong direction. Let me suggest some changes:

Send the generated user's password to the email of who performed the action if that user's email address is not verified. Meaning that the password of new users will always be sent to who created the user (because the email will not be verified yet) and the password reset will be sent to who did the reset as well if the user didn't verify his email (true for installations with fake emails). Making installations with valid emails more secure.
For item 1 if who executed the action doesn't have any email verified the password will be shown on the UI.
If no SMTP was configured the UI will display the password generated. Good for air gaped servers.
To create new users, reset a password or change emails the Two Factor authentication will be required, meaning that the administrator will need to input his password at least. (2FA is remembered for 5min, no need to re-input often for multiple changes).

Our desire here is to enforce a secure system for those using it correctly.

rodrigok on 2 Jan 2020

Switching to zulipchat.

michelpy on 3 Jan 2020

👍3

Switching to zulipchat.

Installing this tomorrow. If tests prove successful, I’ll migrate to it.

Thanks for the heads up.

nahga on 3 Jan 2020

👍1

See, I told ya. They will NEVER put the password field back. This statement is not a TECHNICAL decision, this IS a POLITICAL decision. It's their git repo and they can do whatever they want with it. You're free to fork the code but this git repo will NEVER have that code:

Rocket.Chat was designed to have emails as required for authentication.

AND

we don't want to just bring the password field back, it would be a step in the wrong direction.

Sigh, welcome to open source

Somebody can now at least report to their boss that they paid lip service to the community. Case closed.

bubbapizza on 3 Jan 2020

👍2

I have been in the computer industry before the Internet existed. A long time ago, in a galaxy not that far away, I used to be a dBase II developer, then moved to dBase III and Clipper. Before that, I was an Apple /// developer.

One day at Comdex, I see this dude wearing a F.A.T.E. badge. What's F.A.T.E ?
Former Ashton Tate Employee. Maybe someone can come up with a good-looking acronym for "former rocketchat developer" ?

Sadly, I do not believe in a fork.

The Rocketchat team is acting like they are Bill Gates, Steve Jobs, Larry Ellison, or Mark Zuckerberg.
Good luck.

michelpy on 3 Jan 2020

👍1

Note I have tried to make this as impersonal as possible, this is a criticism of the Rocket team, of whom Rodrigo is just one (very important) member. It is not a personal attack on any one person.

I am sure some of this will be interpreted as 'rude'. As a lot of the Rocket team know, I am blunt, which can incorrectly be construed as rude. I have always done what I have perceived to be the best interests of the project, and usually in private too. Regrettably there are not many easy ways to telling someone they are wrong, and the usual reaction is that they accuse you of being rude because they don't want to hear the truth (none of us do). Quite simply, get over it.

If you make decisions that prompt anger and derision then take it on the chin. Don't try and turn it back and it make it everyone elses fault except your own.

I spent a lot of time trying to promote and assist Rocket, but there are internal forces pushing in different directions, and a real, involved, open source community is not one of them. It is has become lip service so they can wear the open source badge. Too many Rocket.Chat devs just don't understand the concept. It was no longer worth fighting.

This particular decision was the straw that broke the camels back, because it is indicative of the internal struggles at Rocket.Chat and with their partnerships. There is no real open source 'democracy'. It is just their way, or the highway. No consultation or discussion or thought. The community are an irrelevance and ignored. Very sad. It could have been so different. It won't ever be.

It's still possible to set the user's password via REST API

Yes, we are removing the options step by step, we are going to remove this option soon.

What a surprise. Typical. As expected. This thread is no longer about listening. Just pretending to listen with absolutely no intention to reverse any policy.

It's not true, it was driven by our security concerns. We understand your frustration, and we will work to mitigate this. Just bear in mind that we are thinking of all of our users where most of them use our system correctly and desire more security.

Said it before and I will say it again. Nonsense (please check the dictionary definition). It is also unfair to tell people they are not using it 'correctly'. Your website said Rocket is an email REPLACEMENT. We WERE using it as advertised. It is Rocket.Chat devs who have moved the goalposts.

Rocket.Chat are not working to mitigate it. Rocket.Chat could have left this as a switchable option for those who want it. Rocket.Chat have just removed it entirely.

We understand this change has been frustrating for a considerable number of users

Actually your blind belief that Rocket.Chat are right and everyone else is wrong is simple proof of Rocket.Chat not understanding anything. It isn't just frustrating. It has broken established deployments and practices.

This change seems to be Political

It's not true, it was driven by our security concerns.

It is true. This is NOTHING to do with my systems 'security'. it will not CHANGE my systems security because I can STILL change passwords how I want. It is just a whole lot more difficult.

So logically your argument has more holes than a colander.

I also have very good reason to believe it IS to do with some background politics and other commercial considerations, and precious little to do with security.

For anyone interested I'd suggest they take a careful look at some bugs/PRs that might seem out of kilter with expectations, and partnerships, and extrapolate. The evidence is already there.

Our desire here is to enforce a secure system for those using it correctly.

Nonsense. We were using it 'correctly'. Rocket.Chat - the system to REPLACE email. It is on YOUR website. You are enforcing a scheme to fit in with your strategic aims. At least be honest about it.

So now Rocket.Chat enforce the use of email. And are desperately pushing to force the use of 2FA everywhere.

Rocket.Chat have chosen to break the method of operation, not the system administrators.

We are not listening to the community

It's not true, the proof is this thread

Again, complete and utter nonsense. Your are 'listening' but are going to still ignore it. Both ears open but whistling straight though the middle.

Lets see shall we? People have said don't remove any more, and re-enable this option. Are you listening?

Yes, we are removing the options step by step, we are going to remove this option soon.

So despite saying please don't Rocket.Chat are not going to revert this change and are going to remove other options too. Rocket.Chat aren't listening are you?

between the security we want for the product

What Rocket.Chat want. What about what we want? Fine - make sure Rocket.Chat doesn't get XSS attacks and other vulnerabilities in your code. But don't start telling me how to sort out my users passwords. Rocket.Chat aren't listening are you?

we should present this kind of change to the community upfront.

Yes you should, but would it have changed anything? I doubt it. This was always a going to be a fait acompli because that is what your partners want.

since Rocket.Chat was designed to have emails as required for authentication.

As a long time user I should actually say 'Lie' here, but I'll just use 'nonsense'. Again. See your website for details:

Rocket.Chat is free, unlimited and open source. _Replace email_, HipChat & Slack with the ultimate team chat software solution.

It was designed to REPLACE email. Not depend in it. So your statement is unequivocally false.

Proposal

For item 1 if who executed the action doesn't have any email verified the password will be shown on the UI.

Might as well let me set it myself then?? Talk about pointless.

To create new users, reset a password or change emails the Two Factor authentication will be required, meaning that the administrator will need to input his password at least. (2FA is

Oh for the love of god don't. Rocket.Chat are just creating a monster for no gain in security whatsoever. This is just getting worse and worse and worse. I don't want ANY 2FA. My choice. I don't want it foisted on me. Are you listening?? No of course not.

For any one wanting to contact the boss I suggest they go to open.rocket.chat and look for Gabriel Engel in 'Ask Me Anything' and complain like hell, though I doubt that anything will be changed as their priorities and aims have changed.

Rocket.Chat is just being dumbed right down. It is becoming more of a consumer toy than an enterprise system that actually has administrators who know what they are doing. Designed for idiots.

It may be a good time for people using Rocket to consider their long term options.

How sad. Yet another great idea tossed on the scrapheap.

reetp on 3 Jan 2020

👍2

@reetp by saing

I don't want ANY 2FA. My choice.

You mean that you don't want to enter a code from Google Authenticator or sent via email only, or don't like the requirement to enter the password in case you don't have the TOTP or email enabled as well?

I'm really trying to understand this point since the 2FA as described here and in the PR will not require you to configure a TOTP or use your email to receive the code, but, in that case, will require you to enter your password to confirm the operation AND it will be remembered for 5 minutes (configurable via admin). I'd like to understand how this could be a bad thing for you since we are adding a bunch of choices here, just enforcing the password (if it exists).

We are listening, that's why we are here discussing to see if we can have a midterm, saying that we don't want to revert doesn't mean that we will not if there is no other reasonable way.

Would help if you describe why you NEED to enter your own password and use a generated password isn't enough, saying that it's just because you want isn't enough for us, please understand that to revert this and make the system less secure it should have a good reason. I hope we can be more constructive here, I presented some improvements, can we talk about them and see which points still need improvements and why those improvements are required?

Thanks

rodrigok on 3 Jan 2020

You know, this is nearly the EXACT argument that was made, when users were asking for the ability to view messages between users, as administrators...the response was it was something they were considering, but they were trying to asses the privacy and security ramifications. Uhhh, OK... Then when it was finally done, they put it in the paid version ONLY. So, I should expect this to soon be a feature of the paid version of the software, even though it should CLEARLY be something in every version from the start.

sadkins76 on 3 Jan 2020

Switching to zulipchat.

As far as I know, zulip has a hard requirement of email, it's not even possible to create users, just invite them via email or via link.

Rocket.Chat version 2.4 now has the invite links feature where you can generate a link to send to the users so they can register be them selfs.

rodrigok on 3 Jan 2020

@rodrigok I think you've missed the biggest concern here. Every person posting in this thread is in a similar use-case where they do not, or cannot use email for password resets.
Also your solution of not having a email verified will just show the password in the UI....how is that any different from me setting it for the user?
I do not pretend to know the long term plans of rocket chat and it's developers. I do however know that I'll not update this software again, as that seems to be the only way to ensure that the functionality that it currently has will remain intact. This also means that it's usefulness is at an end, and I should investigate alternatives now.

As far as I know, zulip has a hard requirement of email

Thanks for the heads up regarding zulip, I'll do some more checking before deciding if that can replace RC now.

nahga on 3 Jan 2020

As far as I know, zulip has a hard requirement of email

At least they have not pulled a critical failure from under my feet without a warning, and I won't have to worry about the next move that will cripple my system. I'll download it to see if it works for me, and if it does not I'll try something else like mattermost, it's not like there are no alternatives. Plenty of choices out there.

michelpy on 3 Jan 2020

@nahga we are trying to set degrees of security vs freedom here. Since it's a discussion could you explain why a generated password is worse than enter the password you want? From our side I can explain why a random it's better, it prevents administrators to set the same password to all users and prevent administrators to ask the password desired by the user (which may be the same for other systems).

@michelpy we announced the change in our release notes. I already said that we should do those changes carefully in the future and apologized for the inconvenient. Although you can stay in your version until we find a good solution for everyone.

Zulip and Slack do not provide any way to manage the user's passwords, mattermost doesn't allow you to create users, just allow you to reset the password entering the value (as I can see it doesn't solve the problem). Would be awesome to understand how others deal with these scenarios, we are open to discuss and find the best solution possible.

Thanks

rodrigok on 3 Jan 2020

@rodrigok WE are the admins of our installations. Shouldn't the security of OUR servers be of OUR concern and choice? Most of us don't need 2FA, or email verification, or complex passwords. I have an environment of about 50 users, most of which are SHARED logins on SHARED computers. There is no need, want, or requirement that ANY of the users even need to know the passwords to login, as it automatically logs in on start...Are you going to take that away next? The server we run is local, and does not go outside of our network. We use it for internal communication only. This just makes it more difficult to setup and manage, as an admin. I am seriously considering a different solution now. Between the last BS with not being able to readily view users messages, and removing the admin ability to set and change PWDs, this is painting me into a corner which I will be having a harder time excusing my way out of. We, as admins, should have OPTIONS...NOT devs making decisions for us. These kinds of decisions should be left to the admins and users of the software. Its clear that we all understand the risks involved in what we are doing, and it should be clear to the devs at Rocket Chat that we DON'T want this nonsense put upon us.

sadkins76 on 3 Jan 2020

well to give one reason why own passwords are useful: when users lock themself out, they will call the service desk, if the service desk can set an easy one and define that upon next login the user needs to change it, its easier and faster handled. A generated one is hard to spell on a phone and will take more attempts and more time - something service desks should not spend on passwords. I've seen a lot of companies handle it like that (your new password is comp@ny020, have a go, set a new one, good bye). This password often does not even comply to the password policies. It is temporary anyway.

And I think it's not helpful in adding the 2FA discussion into this discussion here as well. It obstructs more things here than it clarifies.

wemu on 3 Jan 2020

@wemu thanks for your contribution. What if we add some settings to configure the generated password? Today our password is something like CTrfCyQSpXwtxsPMt but we could reduce it to 6 chars lowercase only like dak78g or even just numbers as we do for 2FA like 759-321. Would that be better?

rodrigok on 3 Jan 2020

So email will be the primary point of contact no way to get an option to disabled it and take own risk ? Just to know because I want to move to another app ASAP this is taking so many time and no action ... maybe someone want to fork it and continue doing with other point of view ...

villadalmine on 3 Jan 2020

@villadalmine it depends, in the proposal only if you have a verified email it will be sent by email, otherwise it will show on the screen.

rodrigok on 3 Jan 2020

@wemu

We do the same, and we actually ask what password they want, so we can check that it is not something completely weak. My users know who I am, they know my voice, and they are the ones calling. They will give me their password over the phone, when they don't stop by my desk to start with.

michelpy on 4 Jan 2020

You are still asking why do I want to be able to set my own passwords and not use email and not use 2FA?

As if I haven't said it already. Your replies so far have have been nothing more than avoidance or obfuscation. Like a fish wriggling on a hook. The problem is you can't admit the truth and reasoning behind this change can you?

I'll try and put my issues in simpler terms that you can understand as clearly my responses so far have been too complicated.

Email usage

Principle. Because Rocket.Chat promised to "replace email". It says so on your website. Your "raison d'etre". Forcing the use of email for passwords breaks that immediately.

"Rocket.Chat is free, unlimited and open source. Replace email, HipChat & Slack with the ultimate team chat software solution."

It still says that today. I know from lots of discussions with devs that was the original idea. I'm also pretty sure that you don't intend to stay on that path, and intend to change, but you haven't got the courage of your convictions to say so. And I know because you have avoided answering this that this is the real underlying reason.

You want to force use of email, and 2FA (my guess is you will offer deals with your 'partners' to aid this - "no authent? - use partner xyz"). Tell me I am wrong?

Google Authenticator? Let those b*stards anywhere near you? You are joking aren't you?

How the mighty have fallen. The road to hell is paved with good intentions.

Practical. Because I don't use email on some of my Rocket.Chats
That was the beauty of it. No more email.

Passwords

Principle. It is for admins to decide how they want to administer passwords and password security. By all means give them tools to enhance it. But don't tell them how to use them.

Practical.

No email setup for password resets or links (because - well see above)
Can't use text emails (finally fixed but needs updating Rocket)
Bot has no email address so can't change password. No fix yet AFAIAA.

I choose to set my own passwords. You have removed my choice, or at least a simple way to do it. And are about to remove the next simplest way via the API as well. So all I am left with is setting them via the DB. But that then obviates the point of your change, which to is to try and stop admins changing and knowing user passwords. Fail.

I'd like to understand how this could be a bad thing for you since we are adding a bunch of choices here, just enforcing the password (if it exists).

Security and control of access to my systems is my business, not yours. I'll deal with it how I want. I want to set my own passwords because I want too. And that is a good enough reason. Read above for others. If you are going to 'add choices' it means your original argument was flawed. Just add back the ability for me to set my own passwords, and no, I don't expect to be asked for my password AGAIN when I am already logged in as admin. I am not 3 years old.

Would help if you describe why you NEED to enter your own password and use a generated password isn't enough, saying that it's just because you want isn't enough for us, please understand that to revert this and make the system less secure it should have a good reason.

This is an intentional fallacy (you can probably find it here: https://en.wikipedia.org/wiki/List_of_fallacies) whereby you reverse the problem and try to make _us_ justify our reasons rather than you justifying _your_ reasons for changing the status quo, which you have failed to do because we have clearly shown that it can be bypassed. All you have done is remove convenience, not increase security.

Would have been much easier if you had asked for comments first.

You could have left the code there, and made say a DB core switch to enable/disable it making it generally off for most, but the ability to enable for those sysadmins who completely control their own servers. But you are determined not to do that, and that you are right. Heavy handed is an understatement.

As it is now, some will not upgrade, which means they miss out on other bug fixes (You may underestimate the number of off grid systems. Some people are not going to discover this for a while yet as off grid they don't upgrade very often)

You decide which is the worse security scenario - unpatched bugs or admins setting passwords - and let us know.

I'd rather you concentrated on bugs in the core code that may be exploited by external hackers than worrying about users passwords. And also look at some of the many community contributions and issues you have completely ignored (and lost developers over) that are still languishing in github.

Quite frankly I don't need to be taught how to sucks eggs on passwords. It is treating us like children and I find that unpleasant.

This is also indicative of other changes at Rocket.Chat and is just a slippery slope I have seen for a while.

You are dumbing down things to the lowest common denominator because that is the direction that Rocket.Chat is heading. Designed as an 'app' for kids and idiots, not as a flexible application for enterprise. A toy, not a tool. It's all just a game.....

reetp on 4 Jan 2020

Wemu wrote : A generated one is hard to spell on a phone and will take more attempts and more time - something service desks should not spend on passwords.

You are right, but in this case it is even worse, because I now have a ticket to solve why my service desk can't change the password, AND I have become the service desk, because I don't want them to login as root and making manual changes to the database.

I will join many other posters here in saying that attitude is what is driving me away from RC. I have zero confidence in buying the paid app and I have zero confidence that something like that will not happen again in the future. There are plenty of bugs to fix, so reversing and stopping updates is not an option either, which leaves me with zero choice but to go somewhere else.

I have been an admin for 35 years, RC is 0.1% of what I have to manage. My job is to provide my company, my employees, and my service desk with the tools they need to get the job done, not doing it myself with hacks.

michelpy on 4 Jan 2020

👍2

I think I can summarize all this blathering in 2 minor changes:

1) could you pretty pretty please with sugar on top put a checkbox under administration->accounts->"allow administrators to specify user passwords" (you can make it default to off if you want)
2) if 1) is true, put a field under the user account that lets the administrator type in any password he/she wants

If the answer is ANYTHING other than sure, ok, or yes, then ADMINISTRATORS will interpret it as a giant "F* YOU" from the developers. It is such a trivial change that there is no other way to interpret it. If it is not trivial, then please explain in TECHNICAL details why it can't be done.

bubbapizza on 5 Jan 2020

If the answer is ANYTHING other than sure, ok, or yes, then ADMINISTRATORS will interpret it as a giant "F* YOU" from the developers. It is such a trivial change that there is no other way to interpret it. If it is not trivial, then please explain in TECHNICAL details why it can't be done.

I am very sorry to support that this is _not_ a technical move. This is indeed a political move. I interpret it as a F*You. The code was there earlier, we are not talking about spending time writing a new feature here. It costs time to remove the feature, and there is nothing but one thing that justifies going against the community removing a feature that was already there : now, we are going to milk the cow.

michelpy on 6 Jan 2020

just found this when one of our users came to ask for a password change.
Please bring this back for sysadmins.

gillbates on 6 Jan 2020

I moved to matrix.org over the weekend. The attitude and ridiculous arguments for this change from the devs made me lose confidence in this entire project. This is just a big middle finger to everyone who are not using Rocket Chat in "the correct way".

No matter how many pages of crap are written to defend it, this remains a POLITICAL change which adds NO security, and the devs are outright insulting our intelligence by trying to cast it as a security change.

Luckily for me, our use case could be covered by another project. Wish you all good luck moving forward! I'm leaving this farce behind.

sss-wg2 on 6 Jan 2020

👍3

I moved to matrix.org over the weekend. The attitude and ridiculous arguments for this change from the devs made me lose confidence in this entire project. This is just a big middle finger to everyone who are not using Rocket Chat in "the correct way".

Can't say that I blame you. Probably see you there ;-)

I now seriously regret advising a user just recently to use Rocket.Chat, and Rocket.Chat cloud services. Big mistake.

I think Rocket.Chat is likely trying to target a less savvy target audience, and away from enterprise where the competition is too stiff right now.

They look to be dumbing it down, presumably for users/admins who will run it as a service/'app' (see the amount of Snaps..... tells you all you need to know).

So I agree, this isn't really about security, because admins can STILL manually set/change passwords but now with increased difficulty, and probably having to depend on using email.

Ironically if admins use their own backends they can set the user passwords themselves anyway. What are they going to do about THAT 'security' breach???? Block you from using an 'unapproved' backend service that you control yourself? Probably. 'Use our secure partners.....'

Yup - I can see that coming.

So this is just fluff, smoke and mirrors for a political change. Nothing more, nothing less.

reetp on 6 Jan 2020

You are still asking why do I want to be able to set my own passwords and not use email and not use 2FA?

I'm not, just want to know about the necessity of own passwords.

As if I haven't said it already. Your replies so far have have been nothing more than avoidance or obfuscation. Like a fish wriggling on a hook. The problem is you can't admit the truth and reasoning behind this change can you?

I can, it was a security improvement. Maybe we did it in a wrong way, that's why we are here providing solutions and trying to understand the root of your necessity because we have good reasons and want to keep our users secure.

I'll try and put my issues in simpler terms that you can understand as clearly my responses so far have been too complicated.

Email usage

Principle. Because Rocket.Chat promised to "replace email". It says so on your website. Your "raison d'etre". Forcing the use of email for passwords breaks that immediately.

"Rocket.Chat is free, unlimited and open source. Replace email, HipChat & Slack with the ultimate team chat software solution."

It still says that today. I know from lots of discussions with devs that was the original idea. I'm also pretty sure that you don't intend to stay on that path, and intend to change, but you haven't got the courage of your convictions to say so. And I know because you have avoided answering this that this is the real underlying reason.

You want to force use of email, and 2FA (my guess is you will offer deals with your 'partners' to aid this - "no authent? - use partner xyz"). Tell me I am wrong?

Google Authenticator? Let those b*stards anywhere near you? You are joking aren't you?

How the mighty have fallen. The road to hell is paved with good intentions.

Practical. Because I don't use email on some of my Rocket.Chats
That was the beauty of it. No more email.

We understood that and proposed solutions to not depend on email.

Passwords

Principle. It is for admins to decide how they want to administer passwords and password security. By all means give them tools to enhance it. But don't tell them how to use them.

Practical.

No email setup for password resets or links (because - well see above)
Can't use text emails (finally fixed but needs updating Rocket)
Bot has no email address so can't change password. No fix yet AFAIAA.

I choose to set my own passwords. You have removed my choice, or at least a simple way to do it. And are about to remove the next simplest way via the API as well. So all I am left with is setting them via the DB. But that then obviates the point of your change, which to is to try and stop admins changing and knowing user passwords. Fail.

For the Bots we proposed the solution. And proposed the idea to have personal access tokens for bots that admins can manage.

I'd like to understand how this could be a bad thing for you since we are adding a bunch of choices here, just enforcing the password (if it exists).

Security and control of access to my systems is my business, not yours. I'll deal with it how I want. I want to set my own passwords because I want too. And that is a good enough reason. Read above for others. If you are going to 'add choices' it means your original argument was flawed. Just add back the ability for me to set my own passwords, and no, I don't expect to be asked for my password AGAIN when I am already logged in as admin. I am not 3 years old.

Adding more options doesn't mean our original purpose was wrong, we are still delivering a secure way to set passwords, just adding options for those who don't have all the tools to make it happen.

The most important part of the security will be the 2FA asking your password again to confirm actions. We don't think you are 3 years old but protecting you against malicious users. If someone steals your access token via XSS and you are an admin the attacker will gain access to everything and even to the other users' accounts if we do not ask for passwords when setting passwords of other users. You'll have the option to define for how long the system will remember your authorization, it's up to you to define a longer time.

Would help if you describe why you NEED to enter your own password and use a generated password isn't enough, saying that it's just because you want isn't enough for us, please understand that to revert this and make the system less secure it should have a good reason.

This is an intentional fallacy (you can probably find it here: https://en.wikipedia.org/wiki/List_of_fallacies) whereby you reverse the problem and try to make _us_ justify our reasons rather than you justifying _your_ reasons for changing the status quo, which you have failed to do because we have clearly shown that it can be bypassed. All you have done is remove convenience, not increase security.

We already explained the reasons, more than one time. To understand how we can improve or understand that we are wrong we need to understand your reasons.

The bypass case we already explained as well. Can't understand why you are bringing this again.

Would have been much easier if you had asked for comments first.

True, I already apologized.

You could have left the code there, and made say a DB core switch to enable/disable it making it generally off for most, but the ability to enable for those sysadmins who completely control their own servers. But you are determined not to do that, and that you are right. Heavy handed is an understatement.

Just have the option doesn't add any security right? It needs to be composed with other improvements. Again, that's what we are trying to define here.

As it is now, some will not upgrade, which means they miss out on other bug fixes (You may underestimate the number of off grid systems. Some people are not going to discover this for a while yet as off grid they don't upgrade very often)

You decide which is the worse security scenario - unpatched bugs or admins setting passwords - and let us know.

We don't want this scenario, again, that's the reason for this discussion, to find the solution where everyone will feel good to update their instances.

I'd rather you concentrated on bugs in the core code that may be exploited by external hackers than worrying about users passwords. And also look at some of the many community contributions and issues you have completely ignored (and lost developers over) that are still languishing in github.

We deliver security fix often. Can't understand how this helps with this discussion.

Quite frankly I don't need to be taught how to sucks eggs on passwords. It is treating us like children and I find that unpleasant.

Sure, let's find the best solution to keep your system insecure but secure for the ones that have the necessity.

This is also indicative of other changes at Rocket.Chat and is just a slippery slope I have seen for a while.

Another comment uselessness for this topic.

You are dumbing down things to the lowest common denominator because that is the direction that Rocket.Chat is heading. Designed as an 'app' for kids and idiots, not as a flexible application for enterprise. A toy, not a tool. It's all just a game.....

As explained already, the object here is to prevent attackers to have access to your system or, at least, to reduce the damage or the access he will have. It's serious work and I'm here open to discuss and understand all the points. I already said that if we don't find a reasonable solution we may revert the changes, but it's very important to find a way to keep our system secure.

It's not a change to increase security for those who have access to the database or to the server's code.

rodrigok on 6 Jan 2020

👍1

@rodrigok You need to understand that arguing back and forth in this thread about how, why, and what this change really is, and how to move forward is just causing more frustration for the admins that now have angry users screaming at them.

People actually use Rocket Chat for kind of important stuff, and nobody wants to hear that the devs are kinda admitting that they possibly should have done things differently, but that we all need to agree on a perfect solution before anything can happen.

You need to revert this change ASAP, and let people fix their broken systems. Then you can open up a discussion on how to proceed in this domain in the future.

sss-wg2 on 6 Jan 2020

👍3

It's not a change to increase security for those who have access to the database or to the server's code.

I can't actually believe you wrote that. Well, actually I can.

Yes. We know. We keep on telling you this. Keep up.

I said have a superuser account for various functions, but you say 'what if it gets hacked'. And I say what if my whole server gets hacked?? Then what are you going to do?

We don't think you are 3 years old but protecting you against malicious users

That is a contradiction in terms. Either we are 3 years old you need to protect us, or we are grown ups......

How far do you extrapolate this? Are you going to tell me how to manage my servers users and their passwords too? Are you going to tell me which 2FA authentication providers I need to use because you don't trust me to manage that myself (that has a nice profitable ring to it)?

Why not let me worry about my users and their access to my systems. That's my job.

Don't make my life more difficult than it is, which you are doing. Can't set passwords. Bloody password requests ever time I try and do something. Still require emails. Probably some Pin nonsense in time. Just stop. Please. Tell your 'security' consultant to justify their existence some other way.

Quite frankly the system is far more likely to be hacked through vulnerabilities to core code, XSS, etc etc than via this. That's where the real danger lies.

I suggest you start here. Get your own house in order before starting to tell me how to manage my security - it isn't as if you haven't had enough notice is it?

https://blog.risingstack.com/update-nodejs-8-end-of-life-no-support/

2.4.0
Engine versions
Node: 8.17.0

https://github.com/RocketChat/Rocket.Chat/issues/16024

:tumbleweed:

reetp on 6 Jan 2020

@rodrigok

As explained already, the object here is to prevent attackers to have access to your system or, at least, to reduce the damage or the access he will have. It's serious work and I'm here open to discuss and understand all the points. I already said that if we don't find a reasonable solution we may revert the changes, but it's very important to find a way to keep our system secure.

Thanks for all your hard work on making this software available for free to many of us. I really appreciate it.

But you have a bug in your statement above. You said "our system." It's not your system, it's my system. It's your software, perhaps, although in open source even that is debatable. You don't need to worry about how I keep my system secure--I can do that myself.

A true admin cannot be prevented from changing user passwords. Perhaps there are dumbed down admins, that don't have root access to the server, and they could be prevented, but me, as the installer of the rocketchat software, can always change it, no matter what you do. Even if I have to resort to hacking the source code to do it.

Might I suggest if you are blindly determined not to revisit this change, for whatever reason you might have, that you acknowledge the existence of super users/root users/superadmins? For example, knowing that a root user can alter passwords anyway, what if the root user could make a change to allow access to superadmin features, by changing the main method that is called:

ExecStart=/usr/local/bin/node /opt/Rocket.Chat/main_with_superadmin.js

Effectively, the default installation is now "secured" exactly the way you want, but a system admin that has root access to the server anyway, can now make their own decision whether to enable "scary" features that you aren't comfortable with.

If this is not possible, please explain why.

adipose on 6 Jan 2020

I moved to matrix.org over the weekend.

How is that working for you ? Are you using riot.im too ?

michelpy on 6 Jan 2020

As a workaround, set the user's email address to your own email address, then reset the password. This is so easy, it begs the question of what security has been achieved, here... Of course, it only works if you have smtp working, which clearly some do not.

I'm sure before long, we won't be allowed to change a user's email address, either.

adipose on 6 Jan 2020

👍1

Unpopular opinion here -- as annoying as this is, and it really is, its not a terrible call. A bad implementation and deployment, sure--but the change overall I don't fully disagree with. Still, I figured its worth the response of someone who's less personally invested in this issue, but still a little miffed.

In our environment, we've got our RC instance sending out emails, granted a very small amount, via our SMTP relay, which is provided by another of our services. Overall, our company is pretty heavily based in email--from customer relations, to handling our enterprise contacts...if it isn't done by phone, its by email. At this point, RocketChat is strictly used as an inter-office communication tool. From where we stand, if a user has to receive and open an email to set their password--that's fine by me; its not like its any different to nearly any other online service these days...regardless of where its hosted.

You are still asking why do I want to be able to set my own passwords and not use email and not use 2FA?

I'm not, just want to know about the necessity of own passwords.

At our company, we also don't know any of our users' passwords for security purposes...however, for all of our systems, we're still able to manually set a password. That may be a matter of a temporary, or not...but in general, it tends to make things much smoother on the troubleshooting and management end.

Personally, so long as the password generator were to adhere to whatever the password policy is set (if any), I really couldn't care less if an email has to get sent out.

As someone with little to no usefulness in the development realm, take the following with a pinch of salt. Would it be possible, in some way, to provide a means for administrators/super-users, to set the password for a user _without_ the use of the webapp? Now, the idea being--if there's already a means to do this with straight mongo/meteor...why not leverage this, in some way, to allow the functionality being demanded here--but prevent it within the API/GUI?

I guess what I'm saying--I get it. The possibility of a token being stolen and abused is an issue that shouldn't be taken lightly...however, I think its more than abundantly clear that your self-hosted user-base simply want to have greater administration/management control of their deployments. Sometimes that's handled with a configuration file, or a set of permissions...sometimes through other means.

So, with that in mind--would some kind of compromise be available? A means to adjust passwords locally, without the reliance on modifying the database directly? Surely, _surely_, there's a compromise we can make between the product you want to end up with, and what your user-base is expecting.

apaarfus on 6 Jan 2020

👍1

A bad implementation and deployment, sure--but the change overall I don't fully disagree with.

My workaround of changing the user's email address underscores how stupid the concept is. If you have access to change everything except the password, you have access to change the password, too. So they've accomplished nothing, while annoying admins.

An admin-lite is certainly an idea I can get behind. Hell, I would probably use it for some lesser admins I have. But the superadmin is all powerful, and artificially limiting what they can do is counterproductive, and unenforceable anyway.

So what you have here is the perception of added security with none really added.

adipose on 6 Jan 2020

👍1

I still think a means to perform these actions outside of the webapp itself would be a workable starting point for the community at large. Its not as easy as doing it within the GUI, I'll give you that; but I feel like this would be the least annoying thing to everyone involved (including me). At the moment, I'm the sole admin and technical support agent in our company (and have been since I started a few years ago). If I need to run a command/script on the RC instance to perform a task, its really not that big of deal...unless in a mongo command to run--that's still pretty alien to me.

apaarfus on 6 Jan 2020

I still think a means to perform these actions outside of the webapp itself would be a workable starting point for the community at large.

See: https://github.com/RocketChat/Rocket.Chat/issues/15880#issuecomment-569960810

For now, while the API still exists, this script should do the trick.

wreiske on 6 Jan 2020

Sure, but that's not a long-term solution given the current roadmap for this hotly debated issue. As per the current company statement, the API workaround will be removed in a future update--so, while it may work for the time being (though, I never could get that going our testing environment), that's not something that should be heavily relied on going forward...unless a change in statement is released.

So, something along those lines, but while satisfying the company's requirements for security via obscurity is likely the best alternative...if something better cannot be reached by those more in-the-know that myself.

apaarfus on 6 Jan 2020

so, while it may work for the time being

I think you've missed the boat. Either they revert this, or they lose people, not only the ones using the software, but also those that championed and recommended the software as well. They've fulled admitted they made a mistake with this rollout. Not with the policy, but it's implementation and delivery. And they've offered no stop gaps to help. The community, specifically @wreiske, did not RC.

It's abundantly clear they have no plans, short or long term for steering in a direction that will help people in our use case. Unless of course you wait long enough for them to include it in the paid version.... WINKWINK

nahga on 6 Jan 2020

Either they revert this, or they lose people, not only the ones using the software, but also those that championed and recommended the software as well.

Oh, no, I get that. I mean, I can't say I'll be recommending it outside of our current deployment in its current state...but I still don't think a complete reversal of this change is really in the cards. Regardless of demand, the company appears to be pretty adamant that this is the way things are going to be unless some burden of proof is met by the user-base. While @rodrigok has stated time and time again that they want reasoning behind the request for the restoration of this feature--any explanation as to why appears to not meet the required burden of proof they're looking for.

What I'm getting at is that, in lieu of the "Whoops, sorry about that guys" response/reversal, what could be done to salvage this issue? Clearly the requirement of 2FA/Email is not something the community wants; however the company is also pretty clear a GUI/API solution appears to be out of reach for the time being as well....so, what then? Aside from jumping to a different platform, _what can we actually do_ to resolve the matter?

~I dunno, maybe I'm being too optimistic for this issue.

apaarfus on 6 Jan 2020

A file which hasn't been updated since I issued a pull request over a year ago, has had its source changed in the 2.40 install. And yet, in the develop tree it hasn't been touched.

Is it here? https://github.com/RocketChat/Rocket.Chat/tree/2.4.0

wreiske on 6 Jan 2020

No, it's not there. I'm happy to discuss what file it was.

https://github.com/RocketChat/Rocket.Chat/blob/2.4.0/app/ldap/server/ldap.js

See this line here:

In the installed 2.40, it instead has this (in app.js):

It's a fairly innocuous change, and maybe it's a transform that happens when publishing. But it definitely looks different than the source tree.

That's exactly right. When babel compiles it, the template literals get converted to concats. Nothing out of the ordinary there.

wreiske on 7 Jan 2020

👍1

Rocket.chat was used by us to avoid email creation and be more efficient than email. Also, think that some companies doesn't affect an email address when people is not interacting with customer and only need to interact with colleagues. By skipping this main feature, you force user to get also an email address that is a non sense for an alternative more efficient way of communication.

Doctor-Who on 7 Jan 2020

👍3

@rodrigok

Sure, let's find the best solution to keep your system insecure but secure for the ones that have the necessity.

Under this definition of "insecure," apparently all linux machines and windows servers are "insecure." The root users and administrator users of those systems all have access to change the passwords of their users. What makes rocketchat so special?

adipose on 7 Jan 2020

👍2

Unless of course you wait long enough for them to include it in the paid version.... WINKWINK

No, once gone I don't believe it will be seen in a paid version.

They don't want it because they have a target market they are looking at which needs dumbed down security. Simple as that. It isn't about your security. Never was.

It's about the admins of systems that they are trying to attract. These are not enterprise sysadmins. I'd imagine they don't want these systems hacked to bits and giving Rocket.Chat a bad name.

(Note that none of my points about the direction of travel have ever been answered... says all you need to know)

They just never thought through ramifications for quite a few people, or if they did they decided that they could afford to lose those users.

Their public consultancy, debate & discussion on roadmaps is pretty well zero (take it or leave it though the boss has tried with AMA), and their Q & A is terrible with far too little testing on a narrow range of installs.

The developers from closed source backgrounds point their fingers and say OS is rubbish, despite it being their attitudes, decisions, and intransigence that have destroyed any chance of a community.

They now want a community manager (because a few still believe in OS) because the community is extremely weak. However, it is unlikely to grow because the manager will be up against this, and it is a battle they are not going to win. Some developers probably just see it as a convenient way to keep users off their backs.....

I believe the push will probably be on to make Rocket.Chat a simple one click app for $$$ and non-tech admins. The enterprise market is tough. There are easier low hanging fruit that are happy to PAYG. Simples.

They will insist on email and/or 2FA of some sort. Probably in cohorts with partner companies because a lot of these users won't have their own systems for 2FA. So any fix will only be a workaround because they have another agenda to fulfil. You just don't know what it is yet.

See this too. What a lot of nonsense.

https://rocket.chat/2019/11/20/rocketchat-goes-privacy-tech/

Rocket.Chat hasn't been GDPR compliant for ages. They just about got it there for the start date, and then forgot about it. I gave up trying to keep on it because no one was really bothered - maybe it is today but I have no idea now, and I am not sure anyone really checks that.

I give up - the fight is not worth the bother. You make a little progress, and then this sort of thing happens and destroys it all.

At least I can say I tried.

Good luck all. I'm out.

reetp on 7 Jan 2020

What I can say by now is that I want to revert this change. I just need to have a final decision tomorrow morning in our board meeting and we can fix this for the next version and maybe release patches for 2.3 and 2.4.

rodrigok on 8 Jan 2020

👍7

we deploy the rocket chat for private use without any emails. Since this version, our sysadmin has to setup ONE email address to receive the generated email for each account. That is simply like this. By hiding password changing in admin channel is useless. Please revert it back or we will leave.

gillbates on 8 Jan 2020

👍1

Please revert this.
We don't use or have an email server.
We only want simple management with administrator as our team is small anyway.

peara on 8 Jan 2020

👍1

Good news. We decided to revert this change and put the password field back. By this week we will fix it for the next version and release patches for 2.3 and 2.4. I hope this solves all the problems and makes it clear that we care about the community showing that we are always willing to revert decisions if it makes sense. We are learning with this situation in order to prevent the same to happen in the future.

Thanks for your participation and patience.

rodrigok on 8 Jan 2020

👍13 🎉10 ❤2

A sensible decision, at last. A shame that we have had to go through this process. I am not happy with being pilloried for what turned out to be the right point. It shouldn't happen this way.

It causes too much animosity and distrust. I certainly don't need the grief, and I don't expect any of the devs do either.

You also lose customers and goodwill from it. It isn't just about whether one user particularly makes you rich. It's about what happens when they go and tell all their friends.

"It takes 100 good comments to get a good reputation, and just one bad one to destroy it". You have lost a lot of users, and you can imagine what they are going to tell others.

Perhaps in future devs will take a more considered approach when making such substantial changes.

The forums make a sensible place to discuss, but they are seriously under utilised. I don't believe that open.rocket.chat is so good for this type of discussion, and I don't think PRs are great either because many people just don't read github normally - it is a matter of last resort when things go wrong.

Your problem is you have no real 'community' where everyone meets to discuss such things, and that is a situation that badly needs rectifying so that these sorts of changes can be discussed and get everyone on the same page.

You have some seriously smart people out there. Use them to your advantage. Don't just ignore them.

reetp on 8 Jan 2020

👍4 🚀1 ❤1 🎉1

For what its worth, I would still like to see the other options implemented as well as the password field coming back. It would be a nice feature to allow the admin to click one button and send the password reset request to the user if the email is configured. Some environments will utilize the password resets via emails, and some environments don't use email at all. Randomly generating a password in the requirements is nice, too.

Along with that, if email is configured the user should get a notification whenever a password reset attempt has been made, and if it succeeded or failed. I'd also like to see a future where (when email is configured) the user can get emails whenever their login is used on a new device. Potentially even send a push notification to ALL registered devices on the account that a new device has logged in.

Best of both worlds.

Thank you for reverting this change and listening to the community!

Maybe the project board or roadmap for these kinds of changes should be published and allow users to subscribe to them to get email notifications when new changes are purposed?

wreiske on 8 Jan 2020

👍6

We decided to revert this change and put the password field back.

Having it back in 3.0.0 does not solve the immediate problem. I loaded riot.im in a VM on Monday, been busy and did not have time to test further, but you don't have much time left. Fix it for the existing deployment, and fix it fast.

michelpy on 9 Jan 2020

On board with the majority (mostly concerning the bot account situation). We don't rely on emails either because we use external auth (OAUTH2), and there is no need for even setting up a password for human users. I can also understand why someone wouldn't want to plug their rocket.chat with an email server for a simple private deployment. Setting up someone's password as an admin and forcing change on first login for people using internal auth pretty much works flawlessly. That said I stumbled upon this issue because we were in need of adding a couple of bots and couldn't create an account for them, because 1) we don't use email with our instance (and decided we never will) 2) password field has been entirely removed before even integrating a backup solution for bot auth (eg. token as mentioned in this thread), thus blocking us from integrating this bots (not completely, as some pointed out we could still copy another bot credentials from the db to a new user etc ...).

Just my two cents here and thank you for actually reverting to the previous behavior 👍 (even though I sense that adding it to 3.0.0 will make a lot of people angry for not being able to manage their accounts as they want by then).

luminouw on 9 Jan 2020

@michelpy and @luminouw as mentioned in my previous comment we are going to fix this for 2.3 and 2.4 as well.

rodrigok on 9 Jan 2020

👍10 ❤2

@rodrigok Thank you for reverting this change. Looking forward to the new release!

I recently noticed the password field was gone and thought his was a bug - a notice would have been nice for changes of such nature - my whole process of setting up a new user as an admin was impacted.

tholu on 10 Jan 2020

Version 2.3.3 and 2.4.1 were released with the fix.

rodrigok on 10 Jan 2020

Thanks !
What is the recommended method to upgrade from 2.3.1 ? is there a way to trigger an automatic upgrade ?

michelpy on 10 Jan 2020

@michelpy it depends on how you installed your server.

rodrigok on 11 Jan 2020

has this been updated in the offical docker images?

ajayfurbz on 11 Jan 2020

@rodrigok
Ubuntu / Snap, about a year and something ago, currently 2.3.1, obviously installed with an earlier version, it auto-updated itself.

I have been looking around and found no way to check for updates, and no way to undo updates.
This is crazy. Even M!cr$!t W!nd0z3 does better.

You will see more people complaining until it fixes itself. Most of us do not get to the RC admin interface daily; This issue is 6 weeks old, every day that passes sees someone having to reset a password and wasting time why they can't do it the same way they did the last time.

michelpy on 12 Jan 2020

When is an automatic update of a snap package to a new version expected?

bankaichik21 on 13 Jan 2020

Glad to see this change back and the community works :)

I like @bankaichik21 am also waiting for the snap package to be updated so i can set passwords again.

54330 on 14 Jan 2020

Hi, new version 2.4 with this fix should be available this week

LuluGO on 15 Jan 2020

👍5

@LuluGO good news!

bankaichik21 on 15 Jan 2020

Thanks @LuluGO, @theRestThatCommented, great job.
This was a bad move from RocketChat.

malanvaneck on 17 Jan 2020

Thanks community and thanks Rocketchat Team!
I could upgraded from docker to 2.4.1

El vie., 17 ene. 2020 21:34, malanvaneck notifications@github.com
escribió:

Thanks @LuluGO https://github.com/LuluGO, @theRestThatCommented, great
job.
This was a bad move from RocketChat.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/RocketChat/Rocket.Chat/issues/15880?email_source=notifications&email_token=AIOSB2MKBXRX6NVZVBSAT7TQ6II5NA5CNFSM4JS3MLE2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEJI4QSA#issuecomment-575785032,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AIOSB2MPXXAZDC653FNSPBLQ6II5NANCNFSM4JS3MLEQ
.

didacroyo on 17 Jan 2020

@LuluGO snap package 2.4.1 available or not?

bankaichik21 on 18 Jan 2020

👀1

@LuluGO snap package 2.4.1 available or not?

2.4.2 available :)

LuluGO on 19 Jan 2020

2.4.2 available :)

@LuluGO what is the recommended procedure to upgrade from 2.3.1 snap ?

michelpy on 19 Jan 2020

Update : it did upgrade itself to 2.4.2 and the password field is back indeed (untested, it's late).

There was a firewall issue at the same time, could not access it anymore from anything but itself. Difficult to corellate, had to re-create a firewall rule. May or may not be linked, as there was an ubuntu update at the same time.

Will post more update.

michelpy on 21 Jan 2020

@reetp a legend

@rodrigok thank you guys.

Viktova on 4 Feb 2020

😄1

That's great, because we do not even use the e-mail feature at all.
The whole reason we have rocket.chat is so we would not need e-mail :smile:

timothyparez on 24 Feb 2020

😄1 👍1

I'll be darned, well I can eat crow no problem. I never thought they'd bring it back.

rj11 on 2 Mar 2020

this issue also prevents my first default admin user to change his profile in the profile interface for the user... Email reset of password works lol, but anything like adding a profile image is impossible at the moment for mere humans that don't want to read API docs to change profile image.

thorsteinssonh on 30 Nov 2020

Rocket.chat: [Regression] Admin cannot set password for user

Description:

Steps to reproduce:

Expected behavior:

Actual behavior:

Server Setup Information:

Client Setup Information

Most helpful comment

All 123 comments

Linux / Bash Instructions (with curl installed)

EDIT

Answering some topics

A proposal

Related issues