MSC3265: Login and SSSS with a Single Password #3265
Conversation
Signed-off-by: Charles Wright <cvwright@kombucha.systems>
uhoreg
changed the title
uhoreg
added
kind:feature
| the password, using the latest password dictionaries and guessing rules, | ||
| plus possibly specialized hardware to accelerate the computation of the | ||
| hash. | ||
|
|
There was a problem hiding this comment.
Wouldn't the best strategy be to ask the user to log in with an old version of a matrix client? Those send the password in plain text to the server, so it is trivial to steal the users login "raw" password that way for a server admin and as such compromise e2ee security. I'm not sure, if there is a way to solve that...
There was a problem hiding this comment.
Wouldn't the best strategy be to ask the user to log in with an old version of a matrix client?
Oh, that is sneaky. 😈
The easiest target for the attack would be users of a web app, like Element Web. The server simply serves them the old version of the app that sends raw passwords. But then again, if the server is serving up arbitrary code every time a user logs in, I'm not sure there's much hope against this adversary in the first place.
If the users are on a mobile app, then it may be very difficult to get an old version of the software, even if they want to.
So then the most interesting targets are (1) developers, who may run lots of different clients, but who (hopefully) make up a small fraction of the users, and (2) users of desktop clients, who have more freedom over which version they install and run.
The upgrade path is relatively straightforward if your users only ever use a single app to access their account. At some point in time, the app upgrades everyone's passwords, and after that point it never falls back to sending raw passwords ever again. (This is the path I took with Circles. It doesn't even know how to log in with raw passwords. At some point, this will be re-added as an "advanced" option for compatibility with existing accounts.)
If any sort of backwards compatibility is required, where it's ambiguous whether an account is using this proposal or it's using raw passwords, then this will be very tricky indeed.
There was a problem hiding this comment.
The case that I was mostly thinking about, was people pulling old versions of clients from Ubuntu repos or so. By default you currently get a 3 year old version on Ubuntu 20.04, iirc. I don't think this is really solveable. Maybe this can be solved by only allowing the password login first and in a year or so also allow using this for SSSS unlock. Maybe you can add a suggestion of how such a migration could work or why this is not necessarily a concern. One could maybe force users to not use old clients, by disallowing logins with old clients, by adding an extra flag, in which case this would not be backwards compatible after some period and people may learn to not use old clients.
At least this really needs control over the server to abuse this, but on the other hand... that's what E2EE should protect you against. :D
turt2live
added
client-server
| password in long-term storage, it does learn the password whenever a user | ||
| logs in or authenticates through the user-interactive authentication API. | ||
| At that point, a malicious or compromised homeserver could easily decrypt | ||
| all of the lazy user's server-side storage. |
There was a problem hiding this comment.
| all of the lazy user's server-side storage. | |
| all of the user's server-side storage. |
| attacks are not practical. For example, the beta version of Circles uses | ||
| Bcrypt with work factor 14. With this setting, computing a single hash is |
There was a problem hiding this comment.
How does the client know which parameters to use? How would an upgrade be handled?
I see that in another thread you said:
The upgrade path is relatively straightforward if your users only ever use a single app to access their account. At some point in time, the app upgrades everyone's passwords, and after that point it never falls back to sending raw passwords ever again.
Can you explain how this happens? How will the app know if a particular user has been upgraded or not? What if the user doesn't log in on the flag day?
What if my passwords stolen in some other way, wouldn't that adversary be able to generate my SSSS key and impersonate me? The whole reason your password and SSSS key are different is to protect you if the former is leaked. If I didn't want to have to remember my SSSS I would just avoid using the verification myself. |
Yes, they could. It's definitely a trade-off. If you have users who only ever log in to one device at a time, then you have to make a hard choice about what happens when the old device goes away. Either the user loses all of their SSSS, or the SSSS key has to come from something that the user knows. (Or, perhaps with a biometric, from something that the user is, like a fingerprint or FaceID.) The idea that users will remember multiple passwords for each account is nice in theory, but it's not a safe assumption to make in the real world, except for maybe the most sophisticated and motivated users. Even if the two passwords are not exactly identical, they're likely to be very highly related so that the user can easily remember them together. (e.g. "password1" vs "password2") So an adversary who knows one password can throw it into a password cracking engine and find the second password much more quickly. |
|
Closing this one in favor of more recent work on real PAKE authentication. I have a prototype that uses BS-SPEKE to authenticate a Matrix client in the user-interactive auth framework. Then it can also derive an SSSS key from the secret that the BS-SPEKE client derives from an oblivious PRF and a PHF of the password. That improves on this proposal by preventing the CDN from ever logging in as the user. New MSC coming soon(-ish). For now, there are some more details in the Matrix room |
turt2live
added
the
abandoned
The idea here is to use a password hashing function (like Bcrypt) on the client side, to turn one secret (the user's password) into two secrets that we can use for the login password and the SSSS password.
Everything described in this proposal can be done entirely on the client. No changes are required on the server.
In some ways, this proposal might be viewed as a simpler alternative to MSC2957 and MSC3262. Unlike those proposals, this one does not protect the (new, computed) login password against an adversary who owns the homeserver or its CDN. It does, however, prevent such an adversary from obtaining the user's SSSS key.
The proposed scheme has been implemented in Swift in the beta version of Circles.
Signed-off-by: Charles Wright cvwright@kombucha.systems