matrix-org / synapse

Synapse: Matrix homeserver written in Python/Twisted.
https://matrix-org.github.io/synapse
Apache License 2.0
11.79k stars 2.13k forks source link

Support FIDO U2F authentication #2460

Open jrmoserbaltimore opened 7 years ago

jrmoserbaltimore commented 7 years ago

Description

Feature request to support the FIDO U2F authentication specification.

More information

FIDO Alliance Specifications: https://fidoalliance.org/download/

singlerider commented 6 years ago

+1

itay-grudev commented 6 years ago

+1 U2F and/or TOTP. The best scenario is having both but TOTP is the absolute minimum.

awesome-manuel commented 5 years ago

Maybe WebAuthN could provide a common baseline for those types of authentication: https://en.wikipedia.org/wiki/WebAuthn

kazetsukaimiko commented 5 years ago

Hoping this might see more attention, as companies on top of security are starting to require this along with hardware 2 Factor authentication (Yubikey, etc). Some of which have even expressed interest in funding efforts to implement this feature set: https://github.com/vector-im/riot-web/issues/2772

fdp2 commented 5 years ago

Also think such option is mandatory for secutity.

Ralith commented 5 years ago

U2F, or better yet full webauthn, should be strongly preferred to TOTP, as they provide immunity to phishing attacks that TOTP cannot.

dainnilsson commented 4 years ago

I've recently been looking in to Matrix (though still a noob, apologies for any misunderstandings I might have) and from what I can tell, the API specified here: https://matrix.org/docs/spec/client_server/latest#user-interactive-authentication-api should be able to support WebAuthn (both U2F and FIDO2 capable Security Keys) via the Fallback mechanism, assuming the server were to add support for it.

However the reason I'm posting here is that I think WebAuthn credentials can solve another problem, which is to improve the security and UX of cross-signing device keys, as described here https://github.com/matrix-org/matrix-doc/pull/1756. My current understanding (again, I'm new to this) is that for this feature to work, the user needs to keep a master private key secret somehow, which is used each time a new device is created. This private key can be stored encrypted by a passphrase, or entered manually. The point is that it's needed anytime a user signs in on a new client, and it is vital that it be kept secret. It also looks like this feature might not yet be fully implemented, at least not in clients (?).

An observation, and I have no idea if this is the right place to post it or not, is that: By using WebAuthn as part of the login flow, we could simultaneously perform the cross-signing of a new device key using that very authentication, so that the new device is immediately trusted.

A WebAuthn credential is a site-specific long-lived key pair, where authentication is done by creating a signature over a structured message (the client_data in WebAuthn terms), where a challenge parameter is under the control of the caller (application). We could (ab)use this to sign an arbitrary message, by constructing the challenge as challenge = SHA256(message). This allows a third party to verify the signature, allowing it to trust the new device.

Example flow: Alice has an account at matrix.org, and has registered a WebAuthn credential. The credential's public key can be seen and trusted by Bob (itself by cross-signing, or other verification).

Now Alice wants to sign in to riot.im on a new device, she is prompted for her username and password. She's then prompted to insert her Security Key and touch a button on it. Once done, she's logged in.

From a 2FA perspective, the result of the operation is a signature from her credential's private key, over the client_data, which contains a unique challenge chosen by the matrix.org server. Once validated, this proves that Alice is in possession of her Security Key (the "something you have").

From a device cross-signing perspective, the result of the operation is a message signed by one of Alice's trusted public keys, which contains the public key of her new device. These are stored in the network and Bob can automatically verify these and thus start trusting Alice's new device without need for interaction.

Again, not sure if this is the right place to post this or not, but I wanted to share my thoughts on this in the hope that they might be useful. Cheers!

EDIT Disclaimer - I work for Yubico, but am looking at Matrix primarily from a personal interest point of view!

richvdh commented 4 years ago

Related: https://github.com/vector-im/riot-web/issues/2772, https://github.com/matrix-org/matrix-doc/pull/1998

arianvp commented 4 years ago

We could (ab)use this to sign an arbitrary message, by constructing the challenge as challenge = SHA256(message). This allows a third party to verify the signature, allowing it to trust the new device.

This is exactly how openssh uses the FIDO2 API. so it's a sound idea! https://github.com/openssh/openssh-portable/blob/master/PROTOCOL.u2f

dennishwuh commented 3 years ago

It has been months since the first post, any update on this request friends?

ptman commented 3 years ago

@dennishwuh no updates means no change. If there were news, this issue would be updated.

Everyone, stop asking for updates, especially on issue trackers.

In the meantime, use keycloak and openid connect support in synapse to get U2F.

Be-ing commented 2 years ago

@dainnilsson I like that idea! It could be taken a step further for passwordless multidevice authentication by relying on one factor authentication with a roaming FIDO authenticator. Alternatively, two factor identification could work with authenticating from a new device in two different ways: either use two FIDO roaming authenticators to log in immediately, or one FIDO platform authenticator + another factor. In the latter case, this wouldn't log in immediately; it would create a request to approve the new platform authenticator from another device where the user is logged in. In the case of the second factor being a roaming FIDO authenticator, this could be passwordless multidevice 2FA if both devices have platform authenticators. Alternatively, if the second factor is a password and the first factor is a FIDO platform authenticator, 2FA could be done across devices without needing a roaming authenticator at all.

This is similar to an idea I proposed for Discourse for emailless and passwordless authentication. IIUC Matrix already supports emailless registration, but not passwordless.

warriorzz commented 2 years ago

Any updates on this topic? Will this be implemented in the near future?

alx-alexpark commented 1 year ago

2FA is a must!

iav commented 1 year ago

Now it's Fido2.

ptman commented 1 year ago

Synapse is moving towards OIDC. Implement 2FA in your OIDC IDP. https://areweoidcyet.com/

alx-alexpark commented 1 year ago

Is it possible to link oidc to existing accounts?