Future Proposal for Cryptographic Challenge Login Flow and E2E Key Backup Recovery

[ara4n]

Documentation: https://docs.google.com/document/d/1QXMJmLiRWQxZOlynVVk99KhumlM7-7bTrGatBG0AQfU/edit#heading=h.apnhwogtw3jb

I'm recording this as a (very rough and ready, and not yet markdown) MSC in order to capture it, even though the conclusion is consciously to postpone it until a later date.

[uhoreg]

Given that cross-signing is going to require people to type in a passphrase to unlock the self-signing key, and the self-signing key is exactly the right shape to do a cryptographic challenge for logging in, I'm wondering if we should take a look at this again.

[uhoreg]

There's a bunch of prior art that we can look at, such as SCRAM or PAKE. There are also some fairly simplistic protocols that are at least better than what we currently have.

In addition to preventing the server from seeing the password, some potentially nice things to have are:

• allowing the user to authenticate the server. This is a feature of SCRAM, where the user can make sure that the server they're talking to is the server that had previously been given information about their password (i.e. either the server they had previously registered with, or a server that somehow knew their password)
• generating a key with which requests can be signed. This means that a leaked access token would not result in an account getting pwned, since the attacker would also need to forge signatures on the request. There are probably many details that need to be worked out here.

One big potential pitfall is that if a user logs in using a client that doesn't support this new protocol, then their password will be sent to the server anyways.

[richvdh]

I think this has been superceded by MSC2957, MSC3262 and MSC3265.