Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Protect password from server #2925

Closed
notramo opened this issue Dec 26, 2020 · 3 comments
Closed

Protect password from server #2925

notramo opened this issue Dec 26, 2020 · 3 comments

Comments

@notramo
Copy link

notramo commented Dec 26, 2020

Using the same password for login and encryption (e.g. 4S unlocking) would ease the UX.
Also, having the authentication method protect the password even from the server, opens up the possibilities to derive more keys from it later when needed for new protocol extensions (e.g. when P2P stuff introduced, it will maybe require more keys).

I recommend adding another auth method, which would differ from the current password method, e.g. it could be called storepassword, and it would not work on LDAP configs. The procedure would be the following:

  • User enters password.
  • Element derives 2 keys with Argon2 from that password using different salt and different iteration.
  • The first derived key is used for authentication i.e. as login pasword (similarly to current workflow, that key is sent to server in cleartext, then server hashes it again - SHA is enough here - to compare with the one in the DB).
  • The second derived key would be used for encryption of 4S.
  • For UIA, it should always use the first salt to derive the authentication key (first key).

When other protocols (e.g. P2P, or portable accounts) require more keys, then simply use a third different salt.

As @t3chguy commented in element-hq/element-web#15956 (comment), it is possible for a server to lie that it only support plaintext password, and doesn't support this method.

There is only one way to mitigate it: if the method is displayed for the user with proper UX indicating that it is unsecure.
Make locally encrypted (Argon2 clientside then SHA serverside) login default. Brand it as Secure Login or something similar. Display a green shield icon next to the Secure Login text on the log-in screen (the same log-in screen as currently, but it would use the storepassword backend). If an user registers on a Secure Login enabled server, then display a warning:

From now on, you must log in only with Secure Login. Your password is now used for protecting your messages. If you log in with unsecure login methods, your server administrator will be able to decrypt and read your messages, and you will not be able to read them.

If plaintext auth is required, only display a button: Log in with company account. If it is clicked, then show a warning banner:

Warning: This authentication method will make your messages readable to the server administrator and your company.

Maybe a ? button, which displays a dialog explaining it (maybe needs better wording):

Companies use log-in methods which requires your passphrase to be sent to the server unprotected. If you were told by Element to only use Secure Login, then YOU MUST NOT USE THIS METHOD. If you use this method despite you have Secure Login enabled in your account, your messages will be readable by the server administrator and your company. If this is not a company server, but Secure Login is not offered, then you are being attacked by a malicious server.

@uhoreg
Copy link
Member

uhoreg commented Dec 26, 2020

https://github.com/matrix-org/matrix-doc/issues/1699 is the canonical issue for discussing this feature.

@uhoreg uhoreg closed this as completed Dec 26, 2020
@notramo
Copy link
Author

notramo commented Dec 27, 2020

@uhoreg Will #3793 protect the password from the server? Does SCRAM or PAKE provide this feature?

@uhoreg
Copy link
Member

uhoreg commented Dec 27, 2020

Yes

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants