Hello - thanks for filing this. I'm not sure what is meant by "Instead, automatically disable 2fa when recovery code is used." Recovery codes (and the former scratch tokens, which are still usable via older TOTP/authenticator apps) should never disable 2fa for a user. They should instead facilitate access to an account with 2fa enabled if an authenticator app, FIDO key or other 2fa factor is lost, damaged, stolen, etc. The current single recovery code does regenerate each time it is used and a new code can be copied or downloaded under the new Recovery options section on Special:AccountSecurity. We are currently working to improve this user experience in T406281 and hope to have that completed this quarter (October through December 2025).

In T407167#11272603, @sbassett wrote:

Hello - thanks for filing this. I'm not sure what is meant by "Instead, automatically disable 2fa when recovery code is used." Recovery codes (and the former scratch tokens, which are still usable via older TOTP/authenticator apps) should never disable 2fa for a user. They should instead facilitate access to an account with 2fa enabled if an authenticator app, FIDO key or other 2fa factor is lost, damaged, stolen, etc. The current single recovery code does regenerate each time it is used and a new code can be copied or downloaded under the new Recovery options section on Special:AccountSecurity. We are currently working to improve this user experience in T406281 and hope to have that completed this quarter (October through December 2025).

Thank you for your comment. I mean the system should "increase the recovery codes" or "automatically disable 2fa when recovery code is used", but I withdraw the latter idea.
However, because there is a risk that you may fail to obtain the recovery code for some reason, I think we should increase the number of recovery codes issued (to at least three). How do you think?

@T4NeGMp7P4en Why are you adding this as a subtask to every barely related task you can find?

In T407167#11285556, @Reedy wrote:

@T4NeGMp7P4en Why are you adding this as a subtask to every barely related task you can find?

Sorry. It was my misjudgment.

Here is the user story I'm seeing:

1. Have an account
2. Enroll in TOTP 2FA
3. During enrollment write down your ONLY ONE recover code in case you lose your TOTP authenticator
4. Log out
5. Lose your TOTP device
6. Log in, using your only one recovery code, that is now invalidated
7. ???

What are you supposed to do at that point? Because disabling 2FA may require reauthentication. If you get logged out at all (say you close your browser without storing a cookie) you are also locked out forever.

We previously increased the scratch codes from 5 to 10 (in T211831 ) to help in these situations, lowering to 1 is a serious drawback

Note, the most popular end user documentation does not reflect that there is now only ever one code, and how to deal with the situation when your only code is burned.

links:

https://meta.wikimedia.org/wiki/Help:Two-factor_authentication

https://en.wikipedia.org/wiki/Help:Two-factor_authentication

https://www.mediawiki.org/wiki/Extension:OATHAuth

In T407167#11296757, @Xaosflux wrote:

This is a significant problem. As loss of authenticator requires at a minimum TWO codes, that may only be used once to reset an account. (One to log on, one to disable).

That is no longer true. It used to be that you had to reauthenticate when disabling 2FA, but that has changed. Now, you can take any 2FA management action (adding or removing 2FA methods) within one hour of logging in. If you visit Special:AccountSecurity more than one hour after logging in, you will need to reauthenticate.

Of course the user could get logged out, or fail to fix their 2FA setup within an hour, or ignore the messages we're adding T406281, and those may be reasons to increase the number of recovery codes. But it is now possible to redo your 2FA setup with only one recovery code, you no longer need a minimum of two.

In T407167#11296802, @Catrope wrote:

In T407167#11296757, @Xaosflux wrote:

This is a significant problem. As loss of authenticator requires at a minimum TWO codes, that may only be used once to reset an account. (One to log on, one to disable).

That is no longer true. It used to be that you had to reauthenticate when disabling 2FA, but that has changed. Now, you can take any 2FA management action (adding or removing 2FA methods) within one hour of logging in. If you visit Special:AccountSecurity more than one hour after logging in, you will need to reauthenticate.

Of course the user could get logged out, or fail to fix their 2FA setup within an hour, or ignore the messages we're adding T406281, and those may be reasons to increase the number of recovery codes. But it is now possible to redo your 2FA setup with only one recovery code, you no longer need a minimum of two.

It's true that the requirements of disabling 2FA has been relaxed, but I think that's not enough to consider this problem cleared.
By jawp, we found that the reauthentication occur more situations than we thought. The discussion page is HERE.

In T407167#11296802, @Catrope wrote:

In T407167#11296757, @Xaosflux wrote:

This is a significant problem. As loss of authenticator requires at a minimum TWO codes, that may only be used once to reset an account. (One to log on, one to disable).

That is no longer true. It used to be that you had to reauthenticate when disabling 2FA, but that has changed. Now, you can take any 2FA management action (adding or removing 2FA methods) within one hour of logging in. If you visit Special:AccountSecurity more than one hour after logging in, you will need to reauthenticate.

Of course the user could get logged out, or fail to fix their 2FA setup within an hour, or ignore the messages we're adding T406281, and those may be reasons to increase the number of recovery codes. But it is now possible to redo your 2FA setup with only one recovery code, you no longer need a minimum of two.

OK, there is certainly a lack of end user documentation updates. But 1 chance to do it within 1 hour is still quite low. I just worked with someone on VRT that lost access by burning their only recovery code, this isn't a though experiment - it is leading to reduced UX.

Change #1198042 had a related patch set uploaded (by Reedy; author: Reedy):

[operations/mediawiki-config@master] CommonSettings.php: Set $wgOATHRecoveryCodesCount = 10

https://gerrit.wikimedia.org/r/1198042

Change #1198044 had a related patch set uploaded (by Reedy; author: Reedy):

[mediawiki/extensions/OATHAuth@master] Set $wgOATHRecoveryCodesCount = 10

https://gerrit.wikimedia.org/r/1198044

Change #1198042 merged by jenkins-bot:

[operations/mediawiki-config@master] CommonSettings.php: Set $wgOATHRecoveryCodesCount = 10

https://gerrit.wikimedia.org/r/1198042

Mentioned in SAL (#wikimedia-operations) [2025-10-22T12:54:02Z] <reedy@deploy2002> Synchronized wmf-config/CommonSettings.php: T407167 (duration: 08m 29s)

I checked that the patch works well. Thank you so much!

Change #1198044 merged by jenkins-bot:

[mediawiki/extensions/OATHAuth@master] Set $wgOATHRecoveryCodesCount = 10

https://gerrit.wikimedia.org/r/1198044

In T407167#11298863, @Aklapper wrote:

Patch is not merged, so task is not resolved.

Thank you!