search

matrix-org / synapse

Synapse: Matrix homeserver written in Python/Twisted.
https://matrix-org.github.io/synapse
Apache License 2.0
11.79k stars 2.13k forks source link

Store E2EE Keys without an additional password #12386

Open vorletzter opened 2 years ago

vorletzter commented 2 years ago

E2EE seems to be the way forward. Which i consider to be a good thing.

But not all users (or all use-cases) are paranoid about E2EE. There are some issues open to disable E2EE enforcement or at least nudging on Homeserves (e.g. https://github.com/matrix-org/synapse/issues/4367, https://github.com/matrix-org/synapse/issues/4551 https://github.com/matrix-org/synapse/issues/4401).

Matrix seems to get a lot of traction in Corporate Environments (or similar environments like universities, schools, kindergarten) where e2ee is considered to be important but usability is considerable a key factor as well. Having the possibility to use e2ee and not disable it and still be able to participate in a federated environment (even with a warning) could be beneficial to such considerations and generally help the push towards e2e.

An solution would be to enable the possibility to use the Key Storage without an additional password. Just store it. Maybe even warning the user user, that this might pose an security risk to store it without encryption. It might even be considerable to differentiate between "highly secure" and "secure" conversations according to the way users have chosen to store their e2ee keys.

squahtx commented 2 years ago

Could you describe the use case you have in mind?

When creating rooms, there is already an option to not turn on E2EE and chat without encryption.

squahtx commented 2 years ago

There are a few spec proposals to allow using the same password to both log in and access key storage securely: MSC3265, MSC2957 and MSC3262. It sounds like most of the work lies on the spec and client side, rather than the homeserver.

vorletzter commented 2 years ago

I use Matrix with tech illiterate (and sometimes even technophobic) people. I guess the kind of people FluffyChat aims at.

Right now i am trying to get Synapse /w Matrix Corporal to work as a "Kita Info App". The aim is to hand out Credentials (ideal via SSO) to preconfigured Accounts (Display Name, Joined Rooms) to use as way to send/receive Information from Guardians. Maybe similar to what HermanPost (i could only find information in German: https://hermannschule.de/hermannpost.html ) did for schools. Only for Day Care Centers.

One issue i ran into was the enforced E2EE in user initiated 1 to 1 Chat Rooms. When using Matrix Corporal i ended up with some stale sessions (might be bug from Matrix Corporal), and a lot of "cannot decrypt messages". I could try to use an App Service as a Account/Room state Manager to avoid logging in as a user. But i fear, the issues with e2ee encryption might stay. In a similar setting i need to reset Account Credentials on a regular basis and the issues described here But i am open to alternatives to Matrix Corporal / App Services as well.

Considering environments like schools, day care, NGOs, i feel that the "two password" approach might be huge stumbling block.

reivilibre commented 2 years ago

Frustratingly, I don't think there's any support for this in the open source clients that I'm aware of, but one approach that can be taken is to have the SSO server provide the secure backup key.

I think a problem with that (which may explain why it's not in the usual clients) is that a malicious SSO server could trick your client into using a provided secure backup key (even if the user was unaware/didn't want to) and this would be dreadful for security :(.

Perhaps the real problem here is that E2EE is too hard to use for 'technophobic' people and the fix should be to try and improve that (if possible :)) rather than say that they can't have it.

Maybe even warning the user user, that this might pose an security risk to store it without encryption.

One problem with this approach is that warnings are often ignored, and it'd be too easy to make a mistake. You could say that software which claims it is secure should make it hard for you to use it insecurely (you can also imagine that there's reputation at risk; see various literature about PGP and how difficult it is to use properly, e.g. 'Why Johnny Can't Encrypt' and 'Why Johnny Still Can't Encrypt'). In that case, client developers would have to make this option hard to use on purpose, which goes against the intention of making it easy for technophobes.

My opinion right now is that there's a lot of space for clients (or even special-purpose 'simple' clients) to make this easier. Telling someone to write a recovery code on a piece of paper, for example, shouldn't pose much of a problem. Or otherwise, you could even have a client that does exactly what you describe: stores the recovery passphrase in plaintext on the server. However I don't think it makes much sense for it to be part of a mainstream security-focussed client, if you see where I'm coming from?

I'm afraid I don't remember what Matrix Corporal is or does, but running into 'cannot decrypt messages' often means you've run into a bug (unless, of course, there's a good reason you can't access those messages). Ideally those would be fixed rather than making it easier to 'work around' by disabling encryption :-).