Skip to content
This repository has been archived by the owner on Apr 26, 2024. It is now read-only.

Support FIDO U2F authentication #2460

Open
jrmoserbaltimore opened this issue Sep 21, 2017 · 17 comments
Open

Support FIDO U2F authentication #2460

jrmoserbaltimore opened this issue Sep 21, 2017 · 17 comments
Labels
T-Enhancement New features, changes in functionality, improvements in performance, or user-facing enhancements. z-auth (Deprecated Label)

Comments

@jrmoserbaltimore
Copy link

Description

Feature request to support the FIDO U2F authentication specification.

More information

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

@singlerider
Copy link

+1

@itay-grudev
Copy link

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

@awesome-manuel
Copy link
Contributor

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

@kazetsukaimiko
Copy link

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
Copy link

fdp2 commented Apr 19, 2019

Also think such option is mandatory for secutity.

@Ralith
Copy link
Contributor

Ralith commented May 23, 2019

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

@dainnilsson
Copy link

dainnilsson commented Jan 6, 2020

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 matrix-org/matrix-spec-proposals#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
Copy link
Member

richvdh commented Jan 9, 2020

@arianvp
Copy link

arianvp commented Jun 13, 2020

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

@clokep clokep added z-auth (Deprecated Label) enhancement labels Jun 15, 2020
@dennishwuh
Copy link

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

@ptman
Copy link
Contributor

ptman commented Nov 5, 2020

@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
Copy link

Be-ing commented Oct 31, 2021

@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.

@erikjohnston erikjohnston added T-Enhancement New features, changes in functionality, improvements in performance, or user-facing enhancements. and removed z-enhancement labels Nov 1, 2021
@warriorzz
Copy link

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

@alx-alexpark
Copy link

2FA is a must!

@iav
Copy link

iav commented May 28, 2023

Now it's Fido2.

@ptman
Copy link
Contributor

ptman commented May 29, 2023

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

@alx-alexpark
Copy link

Is it possible to link oidc to existing accounts?

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
T-Enhancement New features, changes in functionality, improvements in performance, or user-facing enhancements. z-auth (Deprecated Label)
Projects
None yet
Development

No branches or pull requests