Webauthn is active immediately without checking if the key works...

Well, no. You have to insert it and press it; that's checking if the key works

The rest of this request is basically T232336: Separate recovery codes into a separate MFA method

See also T242031: Allow multiple different 2FA devices and T230042: Allow multiple totp devices

Seems like the setup fail on Firefox with my Yubikey.

If it is correct that log-in only depends on a single key, and I can't configure more keys or scratch codes, then this is terrifying.

You can add many/multiple different yubikeys, as per the "Add key" button

So, what about alternate MFA and in particular scratch codes?

Just tried to use password reset to see if that works without a key, and it asked for the key after using a temporary password. That is sort of correct, but it will not solve the problem with a broken key. I believe the same thing happen with a TOTP (will check tomorrow) but in that case scratch codes are available.

In T244348#6160189, @jeblad wrote:

So, what about alternate MFA and in particular scratch codes?

Already answered in this ticket

In T244348#5853343, @Reedy wrote:

The rest of this request is basically T232336: Separate recovery codes into a separate MFA method

See also T242031: Allow multiple different 2FA devices and T230042: Allow multiple totp devices

In T244348#6160189, @jeblad wrote:

Just tried to use password reset to see if that works without a key, and it asked for the key after using a temporary password. That is sort of correct, but it will not solve the problem with a broken key. I believe the same thing happen with a TOTP (will check tomorrow) but in that case scratch codes are available.

Which is why we've not rolled out 2FA more widely yet.

With solutions that include T180896: Allow functionaries to reset second factor on low-risk accounts

Posted a note at Torget and told people to use TOTP, this solution is not ready for production.

Agree with jeblad, WebAuthn probably shouldn't be live on the production clusters right now, I'm not even seeing any end user guides.

I don't think too many user guides are needed as the feature is pretty self explanitory if you have a security key. The issue is the lack of recovery options. There are definitely scenarios where a user can lose access to multiple security keys and that's in the best case where a user has setup a backup key, I think the majority of users will only have a single key. Is there a reason why scratch codes weren't made available for WebAuthn from the start?

In T244348#6371294, @FozzieHey wrote:

I don't think too many user guides are needed as the feature is pretty self explanitory if you have a security key. The issue is the lack of recovery options. There are definitely scenarios where a user can lose access to multiple security keys and that's in the best case where a user has setup a backup key, I think the majority of users will only have a single key. Is there a reason why scratch codes weren't made available for WebAuthn from the start?

I note, even for the TOTP option with recovery tokens, that hasn't prevented numerous users losing access to recovery tokens and also their device with the 2FA app on it. While it is indeed self service, it is not foolproof.

I think if a user loses multiple security keys, it hardly feels like recovery tokens is going to help much! If they can't keep control of a physical device like that (or in your example, multiple), there are bigger issues afoot.

As for not being made available in the first place with WebAuthn, I guess it was never in the specification for the work (I was not involved till later in the process).

Scratch codes are still applicable here though, there are scenarios where you've lost access to security keys and not scratch codes:

• Security key(s) being reset
• Losing security key(s)
• Security key(s) being broken

I agree it's less likely for multiple keys to not be usable but I think the majority of users will only have one (I presume you have the stats on this anyway).

Yes. And I didn't say it should be done etc.

Hence the fact the task is still open, and so are related tasks like T230042: Allow multiple totp devices, T242031: Allow multiple different 2FA devices, T232336: Separate recovery codes into a separate MFA method which help allowing things like this and make the whole thing more usable

In T244348#6373129, @FozzieHey wrote:

I think the majority of users will only have one.

You are right, I just have one key and I don't see why I should by a second one just because MediaWiki needs an Extrawurst. Github, Nextcloud and Google does support Backup Codes but once again the mediawiki software extension was released without a concept under the assumption that the user is not as stupid as he always seems to be and if he is, then he has had bad luck! For about a half year we all are complaining that this implementation has no waterproof concept and should have never been released. I see four options:

• Disabling Webauthn until there is a recovery option with the reason that the current implementation is not practical and will result in account loss and ultimately frustrated author loss.
• Implementing the with TOTP existing feature of recovery codes in the Webauthn method.
• Still keep saying, what we say since february.
• Hush and hope that the backup function will come at some point.

There is no need (or value) to keep repeating the same stuff. It's not helpful, it doesn't move the conversation on.

Tasks have been filed for longer than this one that suggest to do some of your options. But you have to remember there's priorities for things, and with COVID the foundation isn't working at full speed