Unable to reset e2e if key and password are lost

[johnbrown-yoti]

Description:

Unable to reset e2e if key and password are lost, this stops users from using e2e if they lose their password.

Steps to reproduce:

1. Logout of rocketchat.
2. Clear browser cache.
3. Login to rocketchat.
4. Do not enter e2e password.
5. Go to users e2e password reset page, the option to reset is greyed out.

Expected behavior:

I expected to be able reset e2e if password and key are lost, this would result is previous e2e messages being lost. Without this a user will lose the ability to use e2e if they lose their password & key.

Actual behavior:

User is locked out of e2e without an option to create a new e2e password/key.

Server Setup Information:

• Version of Rocket.Chat Server: 0.70.4
• Operating System: Ubuntu 16.04.5 LTS
• Deployment Method: tar
• Number of Running Instances: 3
• DB Replicaset Oplog:
• NodeJS Version: v4.2.6
• MongoDB Version: db version v3.6.6

[reetp]

Hmmmmm I'm not sure this is a bug per se, and in any event I'm not sure how you would get around it.

What you are proposing is to effectively have a backdoor to your key.

When you generate any public/private key pair with a password, you need that password to unlock it. If you lose the password then that key pair are locked for good. There is no other way to get back into them. That's what makes them pretty safe.

What you are proposing is that a key pair are generated with a password, but if that password is lost then some other password will unlock the key pair. Which is self defeating.

Perhaps @mrinaldhar might like to comment although I think I know what he might say....

[reetp]

As a follow up, the bit that 'may' be a bug is you can't seem to create a NEW key pair if the old one is lost.

No, you wouldn't be able to view old messages, but with with a new pair you could have new conversations.

Currently you would be blocked from having any further encrypted conversations

[reetp]

@rocket-cat label add question

[johnbrown-yoti]

As a follow up, the bit that 'may' be a bug is you can't seem to create a NEW key pair if the old one is lost.

No, you wouldn't be able to view old messages, but with with a new pair you could have new conversations.

Currently you would be blocked from having any further encrypted conversations

This is what I was trying to describe in my original post.

From what I have experienced, multiple people did not take note of their password or were not presented a password. This means that we have multiple users who cannot use e2e. If there was an option to delete the old key (losing old e2e messages) they would then be able to use this feature, currently, they are stuck.

[reetp]

FYI I believe the devs are debating ideas on this. It probably won't get fixed in a hurry but the bug should be left open pending further input.

[fchiacchiaretta]

I had a few users with the same problem, and fixed it at MongoDB level by unsetting "e2e" field for those users in the users collection.

I ran for each user

db.users.update( { username: "put_username_here"} , { $unset: { e2e: "" } } )

Keys have been regenerated on next login, and password prompt showed up again.

[jonnydotgg]

@fchiacchiaretta This doesn't seem to work for me on 0.70.4. Unsetting e2e did allow me to create a new key, and messages encrypted with my old key were not readable, but I was unable to talk in some e2e channels. Creating a new channel allowed my test user to talk but some old channel did not.

I did manage to get this working by getting other users in the channel to clear their cache but this wasn't consistent. Could this be to do with my public key being cached on their side?

[reetp]

This is probably closed with these:

#12169
#12483

[johnbrown-yoti]

@reetp I've had a look at the commits and it looks like there will be a button to run the mongodb command from @fchiacchiaretta 's comment above.

I did some testing for this fix and it doesn't seem to resolve the issue for me. I had a problem where I was unable to send messages into e2e channels even after resetting my key.

[dimm0]

I still don't see the option to reset e2e key in 0.72.0

[phlegx]

Is this option now there? Couldn't find it either.

[dimm0]

Go to users in administration, click a user, and the option is in its menu

[Gummikavalier]

I don't see this option in RC version 3.6.3. I also checked that the admin account has the the privilege edit-other-user-e2ee and that the user I'm testing with has a working encryption key.

[Gummikavalier]

Regarding missing reset password option, one can of course be found under user's own profile, so it is not mandatory, strictly speaking.

I was just worried about any possibility that admin would be able to set a new password for the user. After doing some rudimentary tests, current implementation seems to work so (regardless who does the key/password reset) that when one key is reset, all messages on the channel are decrypted by any existing online user session with working key, and then encrypted again with using new public key. This happens in the client end when such user with an old key sends the next message on the channel.

How E2E is currently implemented protects users in following situations:

1. Database has been stolen from the server. There is no open clients with working keys online at that point to decrypt the messages on the channels.
2. Messages in the transit between client and server, giving extra protection on top of regular TLS encryption of the server sessions. This is because all encrypting and decrypting happens in the client end.
3. Mobile notification system based on the Firebase notification framework (cloud service) and Rocket.Chat gateway service (hosted by the developers of Rocket.Chat and default gateway for non branded Rocket.Chat mobile app) through which the messages previously went in plain text.

However, E2E implementation does not protect users from malicious administrators, who can either reset the keys and passwords directly from the database, or just reset the password for the user, log in, reset the e2e-key in user's preferences, and then wait that any of the other users on the channel send a new message, at which point this malicious admin's new key with its new password will be taken into use on the channel, revealing contents of all messages on it.

[Gummikavalier]

To be perfectly honest nothing protects against malicious administrators with web apps: Since the web client code is downloaded from the server, it would be somewhat trivial to build such version of Rocket.Chat that would save the private key passwords on the database on the server instead of managing them only locally on the browser.

[dimm0]

To be perfectly honest nothing protects against malicious administrators with web apps

Unless user uses publicly-available clients, like in matrix.org

[Gummikavalier]

Yes, sorry. I meant by web app here a client that downloads its code directly from the server it connects to, like browsers do. I suspect that browser based Riot does not do any better on this regard with Matrix.org.

[dimm0]

There are multiple clients compatible with matrix client, and those are completely separate. Any client can connect to any matrix server.

[Gummikavalier]

Yes. I think we are emphasizing different things here. You are talking about individual clients whose code can be audited beforehand, and then checksummed after downloading by people to make sure that they have not been tampered.
And yes; they are perfect for secrecy and this is really the way how efficient E2E should be done.

The usability compromise with strict client approach is that it kills the web client completely from the equation. With web clients you should never paste your private key into any field in the browser or you are at risk of this web application of sending it somewhere else. Same with any client application that looks like a standalone client but are based on running forks of webkit and therefore download parts of their running code from the potentially malicious server.

The real issue is that people love to use browser applications instead of clients, and proof of that is that we are at least 10 years late and not using XMPP-servers with E2E capable clients already. Or why Signal has not completely replaced web client based Slack, Flowdock, Mattermost, Discord or Rocket.Chat group discussion platforms. Signal is also fighting with issues adding more users than just two into the same secret discussion, and people who understand the implications are worried, as it opens up new attack vectors. Keybase.io is an attempt of trying to solve the group discussion puzzle, but it was acquired by Zoom this year and its server end was never self hosted anyway.
I am not proficient at evaluating Matrix.org's security at any meaningful level as I don't have real experience on it. Matrix has had a slew of its own issues in last few years no matter how ingenious some parts of it are. We didn't go Matrix route because of that, along with some other pure usability reasons, and chose Rocket.Chat instead. Regardless of my inexperience with Matrix the basic cryptography security principals are likely to apply on Matrix too. I'm very keen on building a Matrix server when we finally consider it mature enough, though.

Anyway, back to the topic: Rocket.Chat needs to have fully capable web client, but it also needs E2E. Unfortunately these two do not fit into the equation very well at the same time. Not unless web browser makers themselves agree on a standard to import and handle private keys 100% guaranteed privately.

Currently the least to solve the "E2E private key in a malicious web browser field" puzzle would be to create a mini client, a well audited plugin that could be installed into the browser itself to take responsibility of handling the private key for the web client. Or a separate "checker client", an active process that would cross check crucial parts of the loaded E2E javascript code against an audited local code repository on the fly.

Regardless of me whining here, E2E is not completely useless in RC. It protects messages in transit and in database leaks, and also makes reading other people's messages in the database harder than just one javascript query for sysadmins. Therefore it is really good to have. :)