You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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.
The text was updated successfully, but these errors were encountered:
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 calledstorepassword
, and it would not work on LDAP configs. The procedure would be the following: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:If plaintext auth is required, only display a button: Log in with company account. If it is clicked, then show a warning banner:
Maybe a ? button, which displays a dialog explaining it (maybe needs better wording):
The text was updated successfully, but these errors were encountered: