[WIP] MSC2957: Cryptographically Concealed Credentials #2957
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -85,6 +85,10 @@ displays the emoji (or the text equivalent) from the SAS verification emoji | |
| list corresponding to that number. The user remembers/records the emoji for | ||
| later verification. | ||
|
|
||
| Resetting a user's password would happen similarly, with the addition that the | ||
| data in Secret Storage would need to be re-encrypted if the user is using the | ||
| same password for that. | ||
|
|
||
| #### Logging in | ||
|
|
||
| The client generates an ephemeral Curve25519 key pair | ||
|
|
@@ -229,6 +233,13 @@ situation where shoulder-surfing is likely. | |
|
|
||
| ### Man-in-the-middle attacks | ||
|
|
||
| An attacker who is able to eavesdrop on the protocol messages could gain | ||
| information (for example, A<sub>pub</sub>, if they eavesdrop during the user's | ||
| registration) that would allow them to brute-force the user's password. Since | ||
| the sensitive data is encrypted using a key produced by an ECDH, it is not | ||
| enough for the attacker to be a passive eavesdropper; they would need to be an | ||
| active man-in-the-middle. | ||
|
|
||
| TODO: ... | ||
|
|
||
| ### Phishing | ||
|
|
@@ -246,9 +257,26 @@ are managed by an external system. | |
|
|
||
| ## Alternatives | ||
|
|
||
| TODO: compare with various PAKEs (e.g. SRP, OPAQUE) | ||
|
There was a problem hiding this comment. Yes, it would really help to see some discussion here. How is the problem here different from the problem solved by PAKEs? And why is a PAKE not sufficient here? Otherwise it's tempting to say, just grab the current best PAKE (is that OPAQUE?) and run with it. There was a problem hiding this comment. Basically, the tl;dr for why I'm not suggesting a PAKE is that most PAKEs are complicated to implement (is there a good OPAQUE implementation for, say, JavaScript that's readily available?) and/or tied to specific math problems that will be hard to replace if they are shown to be vulnerable. Whereas the scheme presented here uses primitives that are used elsewhere in Matrix and can be easily replaced by equivalent primitives. There was a problem hiding this comment. I was going to say, it's probably easier to implement whatever existing scheme than to design your own. Then I started reading OPAQUE... yikes. SRP and SCRAM are much simpler and use primitives much closer to what you're using. They also have lots of implementations. What makes them not a good fit? I'm not saying you can't build your own PAKE or PAKE-like thing, only that it's really hard. And if you screw up, you'll get the Telegram treatment where the "serious" infosec / crypto people decide to laugh at you instead of looking at your fixed version. All that said, what I've seen so far looks pretty reasonable. I'll find some time later this week to do a full read-through and provide more in depth comments then. There was a problem hiding this comment. I think SRP still requires implementing low-level math stuff. But there's probably at least some decent implementations lying around. SCRAM is pretty decent too, and could be used, though I'd probably want to make some tweaks to it to tighten things up a bit. The main issue with SCRAM is the one vulnerability that I have mentioned in the section where I talk about SCRAM. But aside from that, it should be usable.
Yeah, completely agreed. This is basically just an idea that I had in the middle of the night, and I believe that it's better than SCRAM, but I don't want to push this forward until it's been reviewed by other people who are knowledgeable in crypto. |
||
|
|
||
| ### SCRAM | ||
|
|
||
| [SCRAM](https://tools.ietf.org/html/rfc5802) is another protocol that allows a | ||
| user to authenticate without the server receiving the user's password. It also | ||
| has the feature that the user is also able to authenticate the server since the | ||
| client proves that it has access to the `StoredKey`. One of its goals is that | ||
| the information stored on the server is not sufficient to impersonate a user. | ||
| However, if an attacker has access to the server's storage AND is able to | ||
| eavesdrop on an authentication (or impersonate the server), they can compute | ||
| the `ClientKey`, which is sufficient for the attacker to authenticate with the | ||
| server. This is noted in the "Security Considerations" section of RFC-5802: | ||
|
|
||
| > If an attacker obtains the authentication information from the authentication | ||
| > repository and either eavesdrops on one authentication exchange or | ||
| > impersonates a server, the attacker gains the ability to impersonate that | ||
| > user to all servers providing SCRAM access using the same hash function, | ||
| > password, iteration count, and salt. For this reason, it is important to use | ||
| > randomly generated salt values. | ||
|
|
||
| ### Argon2 | ||
|
|
||
|
|
@@ -278,6 +306,10 @@ two ways. | |
| emoji, providing a hint to users that the client does not support this | ||
| authentication method. | ||
|
|
||
| ## Possible future work | ||
|
|
||
| TODO: combine 2FA? | ||
|
There was a problem hiding this comment. If we have UIA on It feels to soru like 2FA would go beyond the scope of this MSC and would better live as its own MSC, which builds on #2835 and #2839 There was a problem hiding this comment. Yeah. This is more ildly wondering about whether there are any security benefits from integrating 2FA, versus tacking it on as separate thing. I don't think there are any benefits, but I'm not sure enough at the moment that I want to rule it out completely. So this is mainly a note to think about it. |
||
|
|
||
| ## Unstable prefix | ||
|
|
||
| TODO: | ||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe compare how this is better than just having the client hash the password w/ a salt (from the server) and sending the hash to the server, and the server treats the hash as a password and hashes the hash in its db?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If I'm understanding what you're suggesting, I think one main difference is that it would be open to replay attacks. i.e. if someone listens in on your login attempt, they'll see your hashed password, and they can then use that to log in as you.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actually, if I understand your proposal, it is somewhat similar to parts of SCRAM. In SCRAM, the client does PBKDF2 followed by HMAC to generate a
ClientKey. The server stores a hash ofClientKey. This part sounds like it's the same as your proposal. But to avoid replay attacks, rather than sending theClientKeyto the server, the client uses theClientKeyto generate an HMAC of some messages, which the server is able to verify. (More specifically, the client calculates the HMAC using the hashedClientKeyas the key, and then XORs it with theClientKeyand sends that to the server. The server can calculate the same HMAC, since it has the hashedClientKey, XORs the HMAC with what it received from the client to recover theClientKey, and then hashes the recoveredClientKeyto check that it matches the stored hashedClientKey.)