Feature request: Recovery option for Webauthn before it's activated
Webauthn is active immediately without checking if the key works and without recovery options. If my key gets broken after the setup I loose my account. Github and Google have still recovery codes available.
Description
Status | Subtype | Assigned | Task | ||
---|---|---|---|---|---|
Open | None | T244348 Recovery option for WebAuthn | |||
Open | None | T232336 Separate recovery codes into a separate MFA method | |||
Open | taavi | T242031 Allow multiple different 2FA devices | |||
Resolved | Reedy | T268564 Convert OATHAuth to AbstractSchema | |||
Resolved | taavi | T330502 Create oathauth_types and oathauth_devices tables | |||
Resolved | Marostegui | T348693 Drop oathauth_users table from production | |||
Open | taavi | T353962 Add new notifications for additional 2FA being enabled/disabled |
Event Timeline
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.
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.
Already answered in this ticket
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?
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
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