Disable 2FA when Webauthn is being used.

[derritter88]

I have enabled Webauthn on the new Nextcloud version 19. So far it's working perfect but I would like to enable the option if Webauthn is being used then no 2FA needs to be passed.

The current login process is username/password and 2FA OR username/webauthn and 2FA

[ChristophWurst]

Another possibility would be to require a PIN for users who either have 2FA enabled (regardless of which) or have 2FA enforced by the admin. For anyone else it could remain at recommended until all browsers support PINs without issues.

[ChristophWurst]

I found an overview of the browser support at https://developers.yubico.com/WebAuthn/WebAuthn_Browser_Support/

[My1]

Could you share a link to that definition?

well at least the FIDO ppl always had Passwordless login as the big new thing FIDO2 can and U2F cannot do, not sure if I can find a specific link.

[jans23]

I think the proposed fix makes it way better than the current NC.

Beyond this, an ideal solution could be to allow users to choose between passwordless (device+PIN which requires Chromium) and FIDO U2F (password+device which would also work with Firefox). However, I', not sure if this is in scope of this issue.

[My1]

Beyond this, an ideal solution could be to allow users to choose between passwordless (device+PIN which requires Chromium) and FIDO U2F (password+device which would also work with Firefox). However, I', not sure if this is in scope of this issue.

that's basically what would happen if one fixes this, and sets UV to required, the user can login with password and go to 2FA, or they can click "sign in with device" which is passwordless

[nursoda]

Another possibility would be to require a PIN for users who either have 2FA enabled (regardless of which) or have 2FA enforced by the admin.

Mind that we're only talk about webauthn as primary login; so: "if passwordless and device supports PIN and 2FA is NOT enforced, recommend it, if it's enforced, require it". But NOT for webauthn as 2nd factor (as the "password" is the first, and the device already is the second). OK, there might be nerds that even want it then, but that's a separate feature.

[nursoda]

Once the login flow is modified, I suggest that the 2FA flow itself is modified…

Finally managed to create separate feature requests:

• https://github.com/nextcloud/server/issues/34403
• https://github.com/nextcloud/server/issues/34406

[cochon-git]

So, I'm thinking of going just with recommended. At successful login we can check the UV bit and if a PIN was used (Chrome) we skip 2FA, if it wasn't (FF) we go through the current flow.

Another possibility would be to require a PIN for users who either have 2FA enabled (regardless of which) or have 2FA enforced by the admin. For anyone else it could remain at recommended until all browsers support PINs without issues.

From an organisational security perspective, something like this latter option seems to be essential. Where an employee unwittingly registers their token both for passwordless WebAuthn and also for U2F 2FA then in the first scenario an adversary needs only brief access to the user's token (e.g. NFC), without needing anything the user 'knows', essentially 1FA x 2.

Whilst considering anything other than UV=Required to accommodate the current patchy support for WebAuthn, it would seem pragmatic to make UV optionally enforceable at the site level in its own right, completely independently of how (or if) 2FA is configured.

[My1]

fully agree. and using uv preferred is just a problem in itself leading to a false sense of security unless the server can properly act upon whether UV is actually there or not (which most applications likely dont).

I wrote about this in more detail (that is frankly too much for a git comment imo, so I'll just link it)

https://blog.my1.dev/webauthns-userverificationpreferred-and-its-pitfalls

[nursoda]

Full ACK, yet…

Where an employee unwittingly registers their token both for passwordless WebAuthn and also for U2F 2FA

…one might modify apps (or add a server check) to explicitely prohibit THAT user config (specific pitfall) as a quick win.

[My1]

…one might modify apps (or add a server check) to explicitely prohibit THAT user config (specific pitfall) as a quick win.

a pure server check wont work as FIDO is specifically made to not be able to trace things around.

the only thing you can do would be to check both lists for any entries and add both sides' entries to the exclude list when adding a new authenticator which gets interesting to say the least as both the 2nd factor app as well as the core server feature would need to be updated and check for each other (also if someone REALLY wants it, they can just throw out the exclusion list on the client.

The proper way as said would be just 1) requiring UV for device-only login 2) checking UV on the server in addition to the other checks (which is NOT hard, it's literally just a bitflag) 3) skipping 2FA on device-only login

on top of that device+2nd factor just loses out the main point of 2 factors. having two distinct types of factors. having 2 types of possession (especially if it's for example just 2 fido sticks on the same keychain) it becomes stupid.

you wouldnt consider entering a second password after the first password a second factor either, would you?

so there are 3 types of factors.

• something only you know (password/pin)
• something only you have (e.g. a dynamic code generator or a FIDO device or whatever really)
• something only you are (tldr: biometrics)

and having 2 things of the same factor while potentially better than just one thing, certainly has a limit to its usefulness

[ggrzeczkowicz]

I don't know how, but Github make the difference between FIDO authentificator that can be used as passkeys (and then 2FA is not required) and FIDO authentificator that can only be used as security keys (for 2FA).

Cf. https://docs.github.com/fr/authentication/securing-your-account-with-two-factor-authentication-2fa/configuring-two-factor-authentication#configuring-two-factor-authentication-using-a-security-key

For example, when I log on to Github with a passkeys stored in Bitwarden, I don't need to use my Yubikey. And I can't register my Yubikey as passkeys as "this device is reporting partial passkey support".

I think it should be the same with Nextcloud.

[tigernero79]

if you have already stored your yubico token as 2fa it will not be taken as a passkey. the passkey (fido2) allows access without a password because the private key can be stored in the token itself see yubikey (it can store up to 25) or it depends on the developer how they implement the passkey can be stored on their servers, the key stub private is stored by them this avoids saturating the 25 slots available on ybikey. but whether the passkey is memorized or not, it is used not to enter passwords but only pin+touch. the problem in nextcloud is that if you enable webauth fido2 passkey works but the fact remains that it does not disable traditional access by entering the username and password which defeats the purpose of enabling passkey

[cochon-git]

but whether the passkey is memorized or not, it is used not to enter passwords but only pin+touch. the problem in nextcloud is that if you enable webauth fido2 passkey works but the fact remains that it does not disable traditional access

Just bumping my comment from over a year ago, with respect to these recent comments.

The heart of the problem is [still] that when WebAuthn is used for passwordless login the 'pin+touch' part isn't enforced, and some second factor is still required, otherwise you just need to steal the physical key to masquerade as the user. An additional problem is that it's possible to enable the same key as the 2FA step as well, circumventing security beyond the site admin's control.

Simply giving an option to make that UV=Required part mandatory per NextCloud install seems a simple interim solution, given the time it's taking to resolve this fairly fundamental security issue (3 years +).

[ggrzeczkowicz]

if you have already stored your yubico token as 2fa it will not be taken as a passkey. the passkey (fido2) allows access without a password because the private key can be stored in the token itself see yubikey (it can store up to 25) or it depends on the developer how they implement the passkey can be stored on their servers, the key stub private is stored by them this avoids saturating the 25 slots available on ybikey. but whether the passkey is memorized or not, it is used not to enter passwords but only pin+touch. the problem in nextcloud is that if you enable webauth fido2 passkey works but the fact remains that it does not disable traditional access by entering the username and password which defeats the purpose of enabling passkey

Perhaps I misspoke. On Github I have the following configuration: login, password, Yubikey as double authentication, passkey in Bitwarden. When I use my password, I have to use my Yubikey to confirm my authentication. When I log on with Bitwarden (where I have to enter a master password), I don't need to use my Yubikey either.

This is possible because Github does not accept my Yubikey as passkeys (they only accept FIDO devices that implement authentication (fingerprint, password manager...)).

[tigernero79]

I have correctly configured 2 of my yubico 5 and 5c NFC tokens as passkeys on github, it accepts them without any other software

[ggrzeczkowicz]

Sorry, I've realized my mistake, I'm using Firefox, which doesn't let me add a PIN to my Yubikey. So I can only use my Yubikey as a means of double authentication, not as a passkey.

[tigernero79]

if you use google chrome by removing your yubikey like 2fa you can store them as passkeys instead

[ggrzeczkowicz]

In the end, it doesn't change my point, we should be able to do what Github does, i.e. only require dual authentication when a device without authentication has been used as the first authentication method (yubikey without PIN or fingerprint...).

[tigernero79]

if you use passkey you have double authentication (fido2 pin and touch) if you use 2fa then you have to enter your username and password and then use the token

[Samonitari]

if you use passkey you have double authentication (fido2 pin and touch) if you use 2fa then you have to enter your username and password and then use the token

The sum, two factor is correct, but not that way! First factor is the master key on FIDO device (non-discoverable/non-resident key) OR the stored private key (resident/discoverable key) Biometrics or PIN is second factor (user verification in CTAP standardese), touch on a fingerprint-scanner-less device is just user presence (also in CTAP standardese) and not a 2nd factor - touch is only 2nd factor if it is fingerprint scanning. I don't own a key with fingerprint scanner, but I believe if the page/browser asks for user verification and if you also have set PIN on a device like that, it will be PIN XOR fingerprint, so "fido2 pin and touch" is never two factor.

@ggrzeczkowicz : You can add PIN using chrome for once, It's not that hard or painful. Firefox successfully ask for PIN if it is set. Unfortunately, Firefox's support of FIDO2 devices are not finished, but usable. I am in the same boat, but occasionally I launch chrome to check how many resident keys I have, which is another missing feature in Firefox...

[ChristophWurst]

Firefox successfully ask for PIN if it is set.

Can confirm. This seems to have landed recently. It was not possible in the past :rocket:

[Samonitari]

Given how Edge is basically a Chrome, and Firefox also supports PIN now, I vote that passkey login (resident or not on your FIDO key, although the term "passkey" has been twisted to mean resident keys) with mandatory user-verification (which can be requested by Nextcloud) should skip 2FA.

Nextcloud doesn't create resident keys when registering a FIDO WebauthN key, which is a good default IMO, but the possibility would be nice. But that's another issue...

[My1]

Regarding user presence vs verification. Exactly Basically the touch is only basically a captcha in hardware to make sure malware can't try pins and either lock you out or use your stick to do stuff.

[milux]

[...] with mandatory user-verification (which can be requested by Nextcloud) should skip 2FA.

I would suggest to request with the "recommended" option. Then, if the UV flag (user verification) is present in the response, skip 2FA, otherwise ask for another factor. (Which can be the very same key, rendering it useless anyway if the user is lazy...)

Edit: And yes, resident key feature would be nice as well, although I wouldn't consider that one equally important.

[milux]

Firefox successfully ask for PIN if it is set.

BTW: I don't want to disturb anyone's euphoria, but the source code of the NC main branch still says AuthenticatorSelectionCriteria::USER_VERIFICATION_REQUIREMENT_DISCOURAGED in startAuthentication(), so could this be a bug and not related to an improvement in NC?

[My1]

was that for registration where it asks? because technically CTAP2 in general requires a PIN, and chrome tries to fall back to U2F if PIN is set to discouraged to avoid the PIN

[cochon-git]

Which can be the very same key, rendering it useless anyway if the user is lazy...

Which might be fine for a personal setup, but unacceptable to an entity seeking to impose security. I still advocate UV=Required needs to be a simple configurable option for those that require it regardless of any perceived downsides.

[MrRinkana]

I heavily advocate UV=required as default. Sure, I'm all for that it can be overridable on an account/admin level, but the default should be UV=required.

Using (UV=recommended) I believe is problematic as it either (since 2fa should not be skipped in the case of no UV):

• Makes the user use the same key for 2fa, which is useless and might give a false sense of security.
• Makes the user use another 2fa method, which is very likely to be less convenient compared to just inputting the pin
• Makes the user connect another key, which is ridiculous, ruins the login flow.

My comment is all about defaults.

[milux]

I heavily advocate UV=required as default.

What about devices not supporting UV?

[My1]

I would argue that they should be only used as second factor (via twofactor-webauthn), not as a primary sign in method in this workflow

[cochon-git]

I heavily advocate UV=required as default.

What about devices not supporting UV?

It's unavoidable that you need a WebAuthn compliant client to implement passwordless login. If you need to support other devices, then you also need to configure regular password login, with or without 2FA, at your discretion. It's the most common scenario e.g. GitHub, Office 365 etc. allow passwords with TOTP as well as FIDO2.

The issue here is that it's still not possible for an admin to configure and/or mandate single factor login securely, whether or not they have or want the password alternative as a fallback. Passwordless login simply requires UV, I can't think of a single implementation that doesn't, or indeed has this kind of issue.

I would argue that they should be only used as second factor (via twofactor-webauthn), not as a primary sign in method in this workflow

The workflow in this thread is about passwordless login via WebAuthn (FIDO2) without 2FA. But it needn't be a binary choice about coding one use case or another for all installs, simply having a configuration option to enforce UV would resolve this issue for those that need or want single factor login.

The argument about what should be the default settings for those site admins who've not thought about it seems somewhat supplementary. We simply can't make the choice at all at the moment.

[tigernero79]

The thing that is not clear to me in all of this, regardless of 2fa and totp, concerns Fido2, nextcloud already plans to associate webauth devices for password-free access in its latest versions, this is highlighted when for example with a yubico 5 nfc I I associate it in the passwordless authentication section.

The problem arises if I also install alternatives such as "two-facto TOTP Provider and two-factor WebAuth" applications for those who do not have fido2 devices or tokens but have 2fa tokens or want to use yubico as TOTP. in this case if I access nexcloud wanting to take advantage of webautn included in nextcloud after fido2 authentication I find myself having to choose again between totp and fido2 of the applications listed, which should not happen as I have already been authorized with nextcloud's webauth. I do not know if I was clear

[osm-frasch]

We also have a mixed environment here. Some users use TOTP as a 2nd factor and the others use Fido2 with a Yubiko stick. For the time being, I have solved this by creating two different groups. For the users with TOTP, 2nd factor is mandatory. Not for the Fido2 users. They should only log in via the "Log in with a device" link. SSo far for now...

[milux]

We also have a mixed environment here. Some users use TOTP as a 2nd factor and the others use Fido2 with a Yubiko stick. For the time being, I have solved this by creating two different groups. For the users with TOTP, 2nd factor is mandatory. Not for the Fido2 users. They should only log in via the "Log in with a device" link. SSo far for now...

If there was any viable way to automate this approach, I would be fine with it. :shrug: Provided UV is enforced, of course...

[tessus]

I am not sure why this is being discussed for 4 years.

As soon as passphrases are used to login to a web site, 2FA is usually ignored and no 2FA challenge is presented. Nextcloud is one of the few web apps that ignores this standard login flow.

2FA only makes sense for logins via user and password.

[milux]

passphrases

You mean passkeys, do you? :thinking:

[tessus]

Yes, I do.