[Regression] Admin cannot set password for user

Gummikavalier commented 4 years ago

Description:

It seems that admins lost ability in Rocket.Chat 2.3.0 to set a password for new users or reset the password for any old user.

Issue may be related to removal of E2E-password reset functionality from admins in #15777

Steps to reproduce:

Go to Admin-console -> Users
Create a new user and try to set password for it, or try to reset password of any old user.
There is no password field or password reset option anywhere

Expected behavior:

Admins should be able to create accounts with known password to them (to give it out to new user), or reset passwords for old users.

Actual behavior:

There is no user password field or reset option to be found.

Screenshot from 2019-11-29 08-12-04

Server Setup Information:

Version of Rocket.Chat Server: 2.3.0
Operating System: CentOS 7
Deployment Method: tar
Number of Running Instances: 20
DB Replicaset Oplog: enabled
NodeJS Version: 8.15.1
MongoDB Version: 3.6

Client Setup Information

Desktop App or Browser Version: Firefox 70.0.1 and Chromium 78
Operating System: Fedora 31

JASG94 commented 4 years ago

Same problem here running on Docker containers with Kubernetes

cygnusm commented 4 years ago

Same problem!

makibras commented 4 years ago

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.

wemu commented 4 years ago

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/

Gummikavalier commented 4 years ago

@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).

makibras commented 4 years ago

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.

wemu commented 4 years ago

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

makibras commented 4 years ago

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?

wemu commented 4 years ago

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.

JASG94 commented 4 years ago

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.

reetp commented 4 years ago

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

makibras commented 4 years ago

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

reetp commented 4 years ago

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.

Gummikavalier commented 4 years ago

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.

villadalmine commented 4 years ago

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.

wemu commented 4 years ago

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.

makibras commented 4 years ago

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

reetp commented 4 years ago

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

villadalmine commented 4 years ago

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 :)

JASG94 commented 4 years ago

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

MIKI785 commented 4 years ago

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?

didacroyo commented 4 years ago

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

sss-wg2 commented 4 years ago

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.

makibras commented 4 years ago

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.

sss-wg2 commented 4 years ago

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.

reetp commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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.

altapo commented 4 years ago

This should be a configurable parameter

nahga commented 4 years ago

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.

rj11 commented 4 years ago

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 commented 4 years ago

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

rj11 commented 4 years ago

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

villadalmine commented 4 years ago

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

makibras commented 4 years ago

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

sadkins76 commented 4 years ago

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.

michelpy commented 4 years ago

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.

sss-wg2 commented 4 years ago

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.

michelpy commented 4 years ago

@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 ?

bubbapizza commented 4 years ago

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.

wemu commented 4 years ago

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.

michelpy commented 4 years ago

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

nnluc073 commented 4 years ago

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

im-strongthany-zz commented 4 years ago

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.

reetp commented 4 years ago

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

wreiske commented 4 years ago

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

nahga commented 4 years ago

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?

wreiske commented 4 years ago

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

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

Gummikavalier commented 4 years ago

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.

reetp commented 4 years ago

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); } )

RocketChat / Rocket.Chat