Probably should be done using Echo
Description
Details
Status | Subtype | Assigned | Task | ||
---|---|---|---|---|---|
Open | None | T100375 Improve user experience of Two-Factor process | |||
Open | None | T352856 Recovery code improvements | |||
Open | None | T125653 Create new types of notifications | |||
Open | None | T166622 Allow all users on all wikis to use OATHAuth | |||
Resolved | Reedy | T131788 Users should be notified when only two recovery codes are left | |||
Open | None | T150601 Add option to generate new set of recovery codes | |||
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 | |||
Open | PRODUCTION ERROR | None | T368468 Cannot switch 2FA method between TOTP and WebAuthn: InvalidArgumentException: User already has a key from a different module enabled (totp) |
Event Timeline
In OATHAuthKey.php...
// See if the user is using a scratch token if ( !$retval ) { $length = count( $this->scratchTokens ); // Detect condition where all scratch tokens have been used if ( $length == 1 && "" === $this->scratchTokens[0] ) { $retval = false; } else { for ( $i = 0; $i < $length; $i++ ) { if ( $token === $this->scratchTokens[$i] ) { // If there is a scratch token, remove it from the scratch token list unset( $this->scratchTokens[$i] ); $oathrepo = OATHAuthHooks::getOATHUserRepository(); $user->setKey( $this ); $oathrepo->persist( $user ); // Only return true if we removed it from the database $retval = self::SCRATCH_TOKEN; break; } } } }
It should just need the notification stuff plumbing in (after being designed?) somewhere around there
Should there also be a way to generate a new set of recovery tokens, or is the "fix" for that to disable and then re-enable OATH?
From a user experience POV it would be nice to be able to list the tokens at any time as well. Google allows this on https://myaccount.google.com/security/signinoptions/two-step-verification and it has been handy in the past for me.
Yeah. Having to disable and re-enable is a bad user experience for sure.
From a user experience POV it would be nice to be able to list the tokens at any time as well. Google allows this on https://myaccount.google.com/security/signinoptions/two-step-verification and it has been handy in the past for me.
@csteipp can maybe comment more, but I don't know if I agree with this. The backup codes are a shared secret between the server and user, and we should avoid communicating shared secrets as much as possible. It'd be better to only show the codes once, and if the user wants to see them again, just generate brand new codes.
I'm not sure how a list somewhere a user isn't going to probably look is a better solution than a notification that they are much more likely to see
T210075: Send notification when 2FA is disabled/T210963: Send an email when 2FA is disabled do some prep work integrating Notifications
Change 990132 had a related patch set uploaded (by Reedy; author: Reedy):
[mediawiki/extensions/OATHAuth@master] Add notification when user is running out of recovery codes
This message makes more sense in the context of using a token, so ideally IMO it shouldn't be a notification but an interstitial shown after using up the third-to-last token. If a notification is much easier to add, that makes sense, but not sure that is the case?
Maybe both make sense?
An interstitial is dismissed and it’s gone.
A notification (depending on how you deal with it), can still be there for referencing.
They can result in emails (but looks like we might need to wire that in a little differently; the 2FA ones don’t show in the Notifications tab in preferences. I don’t know if this is because they’re marked system, and actually trigger emails anyway) or via Apps too.
They therefore can work without JS.
And they also result in the user getting some notification such as if they log in via apps (rather than needing to do a separate implementation of the interstitial because they reimplement the login screen).
And also, work for our use cases like Striker (combined with the email notifications), where you can use a recovery code on a “third party” site, so wouldn’t see an interstitial inside MW either…
Change #990132 merged by jenkins-bot:
[mediawiki/extensions/OATHAuth@master] Add notification when user is running out of recovery codes
Change #1085919 had a related patch set uploaded (by Reedy; author: Reedy):
[mediawiki/extensions/OATHAuth@REL1_43] Add notification when user is running out of recovery codes
Change #1085923 had a related patch set uploaded (by Reedy; author: Reedy):
[mediawiki/extensions/OATHAuth@REL1_42] Add notification when user is running out of recovery codes
Change #1085924 had a related patch set uploaded (by Reedy; author: Reedy):
[mediawiki/extensions/OATHAuth@REL1_41] Add notification when user is running out of recovery codes
Change #1085925 had a related patch set uploaded (by Reedy; author: Reedy):
[mediawiki/extensions/OATHAuth@REL1_39] Add notification when user is running out of recovery codes
Change #1085925 abandoned by Reedy:
[mediawiki/extensions/OATHAuth@REL1_39] Add notification when user is running out of recovery codes
Reason:
nvm
Change #1085923 merged by jenkins-bot:
[mediawiki/extensions/OATHAuth@REL1_42] Add notification when user is running out of recovery codes
Change #1085919 merged by jenkins-bot:
[mediawiki/extensions/OATHAuth@REL1_43] Add notification when user is running out of recovery codes
Change #1085924 merged by jenkins-bot:
[mediawiki/extensions/OATHAuth@REL1_41] Add notification when user is running out of recovery codes