Page MenuHomePhabricator

Display new recovery code after user logs in with recovery code
Open, Needs TriagePublic

Assigned To
None
Authored By
Catrope
Oct 2 2025, 11:36 PM
Referenced Files
F66741175: image.png
Oct 10 2025, 1:18 PM
F66741162: CleanShot 2025-10-10 at 15.01.02.png
Oct 10 2025, 1:18 PM
F66723006: image.png
Oct 3 2025, 11:13 AM
F66723003: image.png
Oct 3 2025, 11:13 AM
F66723001: image.png
Oct 3 2025, 11:13 AM
F66722998: image.png
Oct 3 2025, 11:13 AM
F66722993: image.png
Oct 3 2025, 11:13 AM
F66721081: image.png
Oct 2 2025, 11:36 PM

Description

A recovery code can only be used to log in once. When a user logs in with a recovery code, we delete their old recovery code and automatically generate a new one, but we don't currently show it to the user.

Instead, we should aggressively show the user their new recovery code, and maybe also encourage them to set up a new 2FA method.

image.png (1,626×776 px, 366 KB)

@AAlhazwani-WMF has given us the design above, but I propose doing this slightly differently. When a user logs in with a recovery code, I propose we:

  • Redirect them to Special:AccountSecurity/recoverylogin , instead of where they would otherwise have gone
  • If the user has JavaScript enabled:
    • Display the page as usual, but show the modal dialog on top of it with the new recovery code as in Amin's design
    • In this dialog, add a message encouraging the user to set up a new 2FA method
    • When they close the dialog, they are on the main Special:AccountSecurity page and the buttons to add a new method are right there
  • If the user does not have JS:
    • Hide the normal page content using CSS, and instead display the new recovery code and the encouragement to set up a new 2FA method
    • Make the "Done" button reload Special:AccountSecurity but in "normal" mode

Event Timeline

@EMill-WMF @AAlhazwani-WMF @KColeman-WMF I editorialized quite a bit while writing this task and propose something different from what Amin originally designed, so please let me know what you think and if I should change any of this

thanks @Catrope @EMill-WMF! a clarifying question on

In this dialog, add a message encouraging the user to set up a new 2FA method

are we suggesting to show this message to everyone? or for instance, if a person has already 1/2/... 2FA methods does it make sense to give them this advise? i also worry about asking people to do multiple important things at the same time. i wonder how we might sequence the communications, here's a few ideas...

1 / display the message immediately in the dialog...

...as an inline text

image.png (2,564×1,232 px, 533 KB)

...or as a inline message (we can decide the urgency of this message and pick between the info icon and the warning icon)

image.png (2,318×1,124 px, 472 KB)

...or as a message (urgency: as above)

image.png (2,312×1,120 px, 477 KB)

2 / display the message once they select the checkbox (as above we can decide between inline text vs inline message vs message)

image.png (2,240×1,094 px, 449 KB)

3 / display a message after they close the dialog

image.png (2,250×1,096 px, 449 KB)

among those ideas, my suggestion would go for 3 to sequence the communication.


i've also included other type of communications like the "copied to clipboard" confirmation. if we find it too intrusive we could also consider using the cdx-tooltip instead of a cdx-message.

are we suggesting to show this message to everyone? or for instance, if a person has already 1/2/... 2FA methods does it make sense to give them this advise?

I think it does, yes. You could have 15 2FA methods set up, but if you logged in with a recovery code, that probably means you don't have access to any of them. That might be OK because that lack of access might be temporary (e.g. you left your security key at home), which is why we shouldn't be extremely aggressive about it, but we should still encourage them to set up a new factor because that's the surest way for them to avoid locking themselves out.

among those ideas, my suggestion would go for 3 to sequence the communication.

With #3 I worry that people will miss it, especially on desktop where it's relatively small compared to the rest of the UI. I think toast notifications are good for success/confirmation messages where it's OK if the user doesn't see them, but for this I would prefer something more prominent like #1c or #2 (but with a warning message instead of an info message, and without the dismiss icon).

i've also included other type of communications like the "copied to clipboard" confirmation. if we find it too intrusive we could also consider using the cdx-tooltip instead of a cdx-message.

I think the copied confirmation is fine as you've designed it.

are we suggesting to show this message to everyone? or for instance, if a person has already 1/2/... 2FA methods does it make sense to give them this advise?

I think it does, yes. You could have 15 2FA methods set up, but if you logged in with a recovery code, that probably means you don't have access to any of them. That might be OK because that lack of access might be temporary (e.g. you left your security key at home), which is why we shouldn't be extremely aggressive about it, but we should still encourage them to set up a new factor because that's the surest way for them to avoid locking themselves out.

among those ideas, my suggestion would go for 3 to sequence the communication.

With #3 I worry that people will miss it, especially on desktop where it's relatively small compared to the rest of the UI. I think toast notifications are good for success/confirmation messages where it's OK if the user doesn't see them, but for this I would prefer something more prominent like #1c or #2 (but with a warning message instead of an info message, and without the dismiss icon).

i've also included other type of communications like the "copied to clipboard" confirmation. if we find it too intrusive we could also consider using the cdx-tooltip instead of a cdx-message.

I think the copied confirmation is fine as you've designed it.

I agree with @Catrope's responses here, including using #2. But let me suggest a couple changes to #2:

  • Don't pop-in the warning after the user checks the checkbox - just have it there from the get-go. I think the user is more likely to be annoyed by the "add a two-factor" warning if it's popping up right after they had to check a checkbox to even get out of the form, and they thought they were done after that.
  • Link the "add a new two-factor authentication method" text in the warning, which would take the user right to do that. It might result in a slightly rate of recovery code saving, but I would expect it to raise the rate of having enough two-factor methods for future logins.

What do you think?

I agree with @Catrope's responses here, including using #2. But let me suggest a couple changes to #2:

  • Don't pop-in the warning after the user checks the checkbox - just have it there from the get-go. I think the user is more likely to be annoyed by the "add a two-factor" warning if it's popping up right after they had to check a checkbox to even get out of the form, and they thought they were done after that.

@EMill-WMF even if displaying the warning message inside the modal is more "annoying", i still think we're giving people conflicting instructions. lets consider the following, we're asking them to:

  • understand that the recovery code they just used is now burned
  • understand that a new recovery code has been created for them
  • (warning them about adding another 2FA method once the modal is closed, or linking outside of the modal)
  • save, copy, or download that new recovery code
  • confirm this action by selecting the checkbox
  • close the dialog to continue with what they originally intended to do, which is logging in
  • and then they realize they're not where they started the login process, they're now on special:accountsecurity

here's an example of the whole flow... from reading through logging in to landing on special:accountsecurity

CleanShot 2025-10-10 at 15.01.02.png (5,627×813 px, 1 MB)

  • Link the "add a new two-factor authentication method" text in the warning, which would take the user right to do that. It might result in a slightly rate of recovery code saving, but I would expect it to raise the rate of having enough two-factor methods for future logins.

What do you think?

i agree that if we would include a link in the modal there's also a risk that they would open the link before actually saving the newly created recovery code which might be problematic. if they don't have access to any of their existing 2FA methods, how would they add a new one? they would need to download another authenticator app, or buy another security key. wouldn't it be better if we really make sure they save their recovery code save before asking them to add a new 2FA method?

image.png (1,700×1,626 px, 420 KB)

cc @KColeman-WMF to pick this up once she's available!

@AAlhazwani-WMF wrote:
Wouldn't it be better if we really make sure they save their recovery code save before asking them to add a new 2FA method?

image.png (1,700×1,626 px, 420 KB)

A heavy plus 1 to what Amin is saying. We don't want to confuse the user and take them away from saving their backup code. We could however make it clear why they need to save this new code (in case they aren't aware that it will no longer work)? i.e. "Your previous code has expired, save your new backup code to a safe place."

We really need to be generating more than one code still. There are way to many ways to log on once and then get logged off.

See T407167 for more user story on this.

It is way to easy to miss a one time screen message, close a browser, etc.

Just to mention here as well - https://phabricator.wikimedia.org/T407167 is resolved, since we have reverted back to 10 user codes. The goal had been to simplify the recovery code experience, and we relaxed the reauth timer to go along with these changes to reduce lockout risk, but this just wasn't a good enough solution. We'll be more cautious before adjusting this again.

Good news on that part. If not captured else where, perhaps when logging in with a recovery code a user notification could be fired (x recovery codes remaining) or something like that?

Good news on that part. If not captured else where, perhaps when logging in with a recovery code a user notification could be fired (x recovery codes remaining) or something like that?

Those notifications should still exist for the older TOTP-attached scratch tokens (relevant code), so it shouldn't be too difficult to add those alerts for the newer recovery codes as well.

In light of there now being 10 recovery codes, we'll have to reevaluate whether it still makes sense to implement this feature as originally designed. This is closely linked with T408025, so I've posted a comment at T408025#11368971 asking @EMill-WMF to opine on what we should do when a user's recovery codes are running low.

This functionality is likely only necessary under the single recovery code model which, as has been noted, is not the current configuration within Wikimedia production and likely never will be again.

This functionality is likely only necessary under the single recovery code model which, as has been noted, is not the current configuration within Wikimedia production and likely never will be again.

Well, as @Catrope mentioned in https://phabricator.wikimedia.org/T408025, this could be adapted to catch the user on login with an interstitial when their recovery codes are low.

I also wonder if we could implement this with an eye toward the multiple kinds of security-relevant things we might want to grab the user's attention with on their way in, now and then. For example (using informal copy, not literally what I would propose):

  • You only have 2 recovery codes left. Use this button to regenerate your recovery codes now and save a new set of 10 codes.
  • This is what we have for your confirmed email address, last updated 5 years ago. Does that look right, and do. you still have access? Do you want to update it?
  • We only have one two-factor authentication method for you. We recommend all users add at least two, to avoid getting locked out. Do you want to add one?
  • You can easily add a passkey for this device, to speed up logging in from this device in the future. Use this button to do that.
  • You don't have an email address set for this account. We recommend users add a confirmed email to their account, to avoid getting locked out. Do you want to add one now?

To be clear, I don't mean implementing all of those things as part of this ticket. I mean that I assume that it might make sense to create a post-login point that checks a variety of conditions that might trigger an interstitial, so that it's pretty straightforward to add those other sorts of examples going forward.

For this specific ticket's focus (recovery codes), I do think it makes sense to use such an interstitial, not just notifications.