MSC1998: Two-Factor Authentication Providers #1998
Conversation
cyphar
changed the title
cyphar
force-pushed
the
msc1997-totp-two-factor
branch
from
db2fa0d
to
bf3176e
Compare
|
@cyphar I've flagged this as ready to review. If that's incorrect, please let me know. I haven't ready the whole thing yet, but the detail is massively appreciated! |
turt2live
changed the title
cyphar
force-pushed
the
msc1997-totp-two-factor
branch
from
bf3176e
to
218eef6
Compare
|
I hope I didn't go overboard, I ended up copying the structure of the actual spec docs but maybe I should've been a bit more terse? |
cyphar
force-pushed
the
msc1997-totp-two-factor
branch
from
218eef6
to
88b3854
Compare
In order to avoid overly-complicating the initial implementation we just provide a basic TOTP authentication flow and a recovery code flow. Signed-off-by: Aleksa Sarai <cyphar@cyphar.com>
cyphar
force-pushed
the
msc1997-totp-two-factor
branch
from
88b3854
to
97d9605
Compare
|
@turt2live I've made the corrections you mentioned. One thing with using |
|
|
||
| * `GET /_matrix/client/r0/account/twoFactor` to get the current state of enabled providers for the account. | ||
| * `POST /_matrix/client/r0/account/twoFactor` to configure providers. | ||
| * `DELETE /_matrix/client/r0/account/twoFactor` to disable providers. |
There was a problem hiding this comment.
turns out I can't read, as vdh points out these should be two_factor: #1998 (comment)
|
@dainnilsson please move your comments to threads on the diff so people can reply. |
| ### `POST /_matrix/client/r0/account/twoFactor` | ||
|
|
||
| This endpoint allows the client to enable (or reset) a two-factor provider. In | ||
| order to avoid users locking themselves out of their accounts, servers should | ||
| enable `m.login.two-factor.recovery` if it is not already enabled for the user. |
There was a problem hiding this comment.
Some 2FA credential variants will require more round-trips to set up, for example WebAuthn (https://www.w3.org/TR/webauthn/). Does this endpoint allow for that? For example, when setting up a credential the client needs to first get a challenge, and then provide a response based on that challenge to the server. Potentially other protocols might require even more round-trips to complete.
Likewise for TOTP, it's common that as part of credential registration the server requires a valid OTP for the new credential before activating it, to make sure the client has correctly received and supports the parameters used. Perhaps this should be part of the m.login.two-factor.totp registration flow?
There was a problem hiding this comment.
Perhaps I'm misunderstanding WebAuthn (and I'd love to hear more about it -- I've only interacted with the first-gen FIDO stuff very superficially), isn't it intended to replace passwords as one of the factors of authentication (rather than being an alternative MFA mechanism)? If so, then adding a new login flow (separate to this proposal) would seem to be a better path forward to have WebAuthn supported in Matrix.
But I think you're right that the current design of Matrix's login flow system doesn't allow for multiple ping-pongs between clients and servers. You'd need to create separate login stages (which seems to me to be a little bit scary since forgetting to include a login flow step means that the authentication would succeed if I understand how it works correctly).
Perhaps this should be part of the m.login.two-factor.totp registration flow?
Yes it probably should be, and all MFA registration flows I can think of work that way...
There was a problem hiding this comment.
WebAuthn can be used in several ways. Also as single factor. But I believe most common is to use instead of SMS or TOTP codes as second factor.
| ### `POST /_matrix/client/r0/account/twoFactor` | ||
|
|
||
| This endpoint allows the client to enable (or reset) a two-factor provider. In | ||
| order to avoid users locking themselves out of their accounts, servers should | ||
| enable `m.login.two-factor.recovery` if it is not already enabled for the user. |
There was a problem hiding this comment.
One other consideration is that a single 2FA provider may need to support multiple credentials. While I think this might be possible under the current API by leveraging the provider params dict, it does overlay a lot of functionality on a single endpoint. For any given provider we not only have "enable/reset", but also "add credential" and "remove (specific) credential". I'm not sure if this warrants additional endpoints or not.
Done! |
turt2live
added
the
needs-implementation
|
Any updates on this? I would like to have this merged as I would love to use WebAuthn as second factor when authenticating. |
|
Same question.
|
|
I haven't had much time to review this after I first posted it. It is still a feature I'd like (I still use Matrix daily and wish we'd have 2FA) but it seems that WebAuthn would require a more flexible design than the pretty basic one I came up with here -- this feature would almost certainly turn out better if it's handled by someone with more experience dealing with authentication. |
|
Isn't this work effectively overshadowed by the OIDC initiative the matrix foundation is currently following? From what I know, it'd essentially move authentication to somewhere else, which then has to implement webauthn instead. (The focus being that, by default, a server will use matrix-authentication-service as an internal OIDC provider, which already has an issue open about this: matrix-org/matrix-authentication-service#18) |
|
yes, OIDC would obviate the need for this. For now we'll keep it open until we are fully committed to OIDC. |
|
Is there any follow-up on this feature? |
Rendered
Implements: #1997
Signed-off-by: Aleksa Sarai cyphar@cyphar.com