2FA is not necessarily legal everywhere in the world.

I honestly don't think this is true, any reference of outlawing 2FA?

My biggest concern:

• Imagine I have 2FA and a sensitive user right. Then I lose my phone and need to reset it. The way it currently works is that I (or someone from T&S) disable 2FA until I set a new one. Then how this is going to be affected? Will you let users have the right temporary until they set 2FA again? for how long?...

For a while now it's been policy that certain groups (https://meta.wikimedia.org/wiki/Category:Global_user_groups_that_require_two-factor_authentication) are required to have 2FA enabled. We can now, sort of, enforce that. By adding groups to $wgOATHRequiredForGroups, users will be unable to use the rights granted to them by that group until they enable 2FA. This will be displayed privately in Special:Preferences. This will not stop an attacker who compromises an account and then just turns on 2FA to access restricted permissions, rather it's to remind users who are supposed to, that they need to enable 2FA by preventing them from using their rights until they do so.

@jrbs, @Reedy, who should sign off on enabling this? And could we get a list of groups it should apply to? Note that we can currently only do it for local groups, not global ones.

In T150898#7720672, @Legoktm wrote:

@jrbs, @Reedy, who should sign off on enabling this? And could we get a list of groups it should apply to? Note that we can currently only do it for local groups, not global ones.

I'm not totally sure. The usual blocker is bandwidth for undoing 2FA on request because we have no way to scale that at the moment. But it's obviously creating a weird world in which 2FA is required but not mandatory which is not ideal.

T&S has a bunch of other stuff to keep tabs on at the moment but I'll see what the team thinks at the moment.

In T150898#7746049, @jrbs wrote:

In T150898#7720672, @Legoktm wrote:

@jrbs, @Reedy, who should sign off on enabling this? And could we get a list of groups it should apply to? Note that we can currently only do it for local groups, not global ones.

I'm not totally sure. The usual blocker is bandwidth for undoing 2FA on request because we have no way to scale that at the moment. But it's obviously creating a weird world in which 2FA is required but not mandatory which is not ideal.

T&S has a bunch of other stuff to keep tabs on at the moment but I'll see what the team thinks at the moment.

I'd agree that it's problematic to do this without some type of accompanying support process in place for when people lose devices, lose scratch codes, etc. since it's difficult or impossible to fully automate those re-verification steps at this time. For the non-wikitech wikis mentioned within the task description, enforcing 2FA for the suggested groups is just a config change, I believe, which could happen soon if folks find a greater value in having said config changes put into production over properly-defined and scaled support.

In T150898#7746049, @jrbs wrote:

In T150898#7720672, @Legoktm wrote:

@jrbs, @Reedy, who should sign off on enabling this? And could we get a list of groups it should apply to? Note that we can currently only do it for local groups, not global ones.

I'm not totally sure. The usual blocker is bandwidth for undoing 2FA on request because we have no way to scale that at the moment. But it's obviously creating a weird world in which 2FA is required but not mandatory which is not ideal.

T&S has a bunch of other stuff to keep tabs on at the moment but I'll see what the team thinks at the moment.

It would be nice if we could get updated statistics on how many users in these groups don't currently have 2FA enabled, as ideally that's how many more users will be "forced" to enable 2FA. If it's one or two people, I think the increased support burden is going to be pretty minimal and not worth delaying on. If it's a significant amount, then I think the support concern is very reasonable, but that we also have a lot of valuable accounts NOT protected by 2FA, which this change would hopefully remedy..

Relatedly, after I finish T145915, next on my list is working on T242031: Allow multiple different 2FA devices and siblings (have some WIP stuff locally), which I hope will reduce the support burden since it'll be harder for people to get locked out. Hopefully I will have time to get that done within the next month or so. We could also wait on that.

I think we can start enforcing 2FA for interface-admins, since we already require 2FA for those per policy.

In T150898#8587901, @Zabe wrote:

I think we can start enforcing 2FA for interface-admins, since we already require 2FA for those per policy.

We can, but that introduces at least a few hundred more users (e.g. P43319) into a system that has several critical, manual processes which still are not explicitly owned or fully-resourced by any WMF teams AFAIK.

Maybe this wasn't designed for the following use case, but how would this work for regular users in private wikis with read/write restricted (e.g. officewiki to name one)? If rEOAT498dcfeb80fc: Require OATHAuth for membership in specified user groups description is accurate ("their membership in those groups will be disabled") it'd appear that enabling $wgOATHRequiredForGroups for the user group would prevent them from even log-in?

If the above is true, I'd say the user should be offered some limited-access to their user space (User, User Talk, subpages) and Special:Preferences so they can set up 2FA; while disallowing everything else until 2FA is enabled, including read access for the rest of the pages.

Was done for interface admins yesterday: rOMWC74c6f82c8449: OATHAuth: Mark interface-admin as requiring 2FA

One thing that I think would make a lot of sense conceptually is to require elevated security mode for everything (T197160: All security-sensitive MediaWiki functionality should require elevated security) except when you use 2FA. Good motivator as well.

Change #1133245 had a related patch set uploaded (by SBassett; author: SBassett):

[operations/mediawiki-config@master] OATHAuth: Mark checkuser and suppress as requiring 2FA

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

abusefilter-maintainer is likely more important than abusefilter-helper (the later is a read only group)

https://www.mediawiki.org/wiki/Wikimedia_Security_Team/Two-factor_Authentication_for_CentralAuth_wikis and https://meta.wikimedia.org/wiki/Help:Two-factor_authentication should be updated to reflect the changes for 2FA requirement/enforcement, once everything has been decided/implemented.

In T150898#10701397, @gerritbot wrote:

Change #1133245 had a related patch set uploaded (by SBassett; author: SBassett):

[operations/mediawiki-config@master] OATHAuth: Mark checkuser and suppress as requiring 2FA

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

This needs messaging to the communities before it's made live. The expectation has been clear for interface admin for some time vice those two roles. This would be quite an extension (though my personal opinion is that it should be done).

A quick (subjective) review of the state of Wikimedia 2FA in terms of usability:

TOTP/both:

• Potential scaling issues if more users use it and more account recovery needs to be done. (See T180896: Allow functionaries to reset second factor on low-risk accounts.) IIRC CU/OS would not be a significant increase; bureaucrats would be an order-of-magnitude increase.
• 2FA makes login more annoying because we are asking for it too often: T203256: OATH (2FA) needs an option to remember device but not keep user logged in, T208668: Do not ask for password on reauthentication when 2FA is enabled
• No autofill/typing support: T356004: Help password managers to detect TOTP login input, T289086: Allow iOS/macOS/iPadOS to autofill 2fa codes, T151738: OATH code field should show numeric keyboard on mobile devices

WebAuthn:

• In general it has never been seriously tested or reviewed. Not sure if we have a good sense of how well it works, other than with Yubikeys (which are used by several people, so that aspect is reasonably well-tested). T232639: Get UX review for OATHAuth/WebAuthn
• T242031: Allow multiple different 2FA devices - probably the biggest issue now that login is single-domain. Cannot be used with the (less fragile) TOTP as a fallback, cannot be used with scratch tokens, you cannot use multiple devices... Thanks to @taavi this is close to getting fixed, though.
• Support for more WebAuthn mechanisms: T358771: Unable to login on iPhone with Passkey Enabled, T363652: publicKey.pubKeyCredParams is missing at least one of the default algorithm identifiers: ES256 and RS256
• {T268384}

Other methods that might be easier to use:

• T150902: SMS based 2FA - there are pros and cons here, but I think even if we had this, we'd want to disallow it for high-value accounts as it's less secure. So for the purposes of this discussion, IMO moot.
• T352864: Use Wikipedia Mobile app as 2FA?

Other issues:

• limitations of the forcing mechanism: T390386: Be able to force OATHAuth for certain global user groups
• missing monitoring: T150903: Alert sre/security on many 2FA failures T158379: Warn the user after a certain number of failed 2FA attempts
• T301992: Insert CheckUser row events during certain 2FA actions

Not represented in those tasks is the community perception that the MediaWiki 2FA implementation is fragile and prone to locking people out of their accounts because they lost their authentication device and their scratch codes don't work. Whether this was ever true is unknown, but I certainly know of multiple people who say it happened to them years ago. Those stories seem to be less prevalent now, but the perception (and the way we talk about 2FA) has not really changed.

Some of those lockouts were probably caused by users forgetting to save or update their scratch codes. I signed up for a website recently that after displaying the scratch codes, hid them and made me enter one to prove that I saved them correctly. That might be a good idea for MediaWiki as well -- T391737: Require users to prove they saved their scratch codes

Others lost their scratch codes and don't know it yet. Some websites prompt users to check their scratch codes yearly, which may also be a good idea. This is currently somewhat prevented by the decision in T131788/T145915 that scratch codes should only be shown once. Retrieving my scratch codes from where they are stored would be annoying enough, having to update them yearly would be more annoying and might even cause more errors or insecure practices.

FWIW, while I'm not saying our 2FA can't be improved but it's drastically much better than what it used to be. For example regarding scratch tokens, now there is a button to download a file containing those. I hope we can make even further improvements such as turning the txt file into a nice looking PDF ready for print but it's already quite an improvement.

Our 2FA UX is not perfect but it's not a disaster either.

In T150898#10735724, @AntiCompositeNumber wrote:

Whether this was ever true is unknown, but I certainly know of multiple people who say it happened to them years ago.

I imagine if it would be still happening, we'd hear about it? But maybe we could just ask people to test their scratch tokens by doing one scratch token based login. (In the UI they have been renamed to "recovery code", FWIW.) But maybe only after T232336: Separate recovery codes into a separate 2FA module (which itself is blocked on multi-device support).

I signed up for a website recently that after displaying the scratch codes, hid them and made me enter one to prove that I saved them correctly. [...] Some websites prompt users to check their scratch codes yearly

I think these are uncommon practices, none of the large sites where I have used scratch tokens do it. There's a bunch of other things we could do, like showing the number of tokens left (again, after T232336: Separate recovery codes into a separate 2FA module).

But mainly I think, we just need to support multiple devices. If you choose between TOTP, WebAuthn via your OS, WebAuthn via your mobile phone and scratch tokens, it's pretty unlikely all of those would break / get lost at the same time.

Change #1133245 merged by jenkins-bot:

[operations/mediawiki-config@master] OATHAuth: Mark checkuser and suppress as requiring 2FA

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

Mentioned in SAL (#wikimedia-operations) [2025-05-20T11:06:54Z] <ladsgroup@deploy1003> Started scap sync-world: Backport for [[gerrit:1133245|OATHAuth: Mark checkuser and suppress as requiring 2FA (T150898 T389727)]]

Mentioned in SAL (#wikimedia-operations) [2025-05-20T11:12:55Z] <ladsgroup@deploy1003> ladsgroup, sbassett: Backport for [[gerrit:1133245|OATHAuth: Mark checkuser and suppress as requiring 2FA (T150898 T389727)]] synced to the testservers (see https://wikitech.wikimedia.org/wiki/Mwdebug). Changes can now be verified there.

Mentioned in SAL (#wikimedia-operations) [2025-05-20T11:20:52Z] <ladsgroup@deploy1003> Finished scap sync-world: Backport for [[gerrit:1133245|OATHAuth: Mark checkuser and suppress as requiring 2FA (T150898 T389727)]] (duration: 13m 57s)

This needs messaging to the communities before it's made live.

For the record, it seems like individual CU/OS were not notified directly despite the change being in effect.

Note that the above config change (T150898#10838554) has been reverted: https://gerrit.wikimedia.org/r/1148956, https://sal.toolforge.org/log/BbkO9ZYB8tZ8Ohr0ZZxy. The reasoning for this is that the WMF needs more time to sufficiently communicate to affected users.

In T150898#10845230, @Sdrqaz wrote:

This needs messaging to the communities before it's made live.

For the record, it seems like individual CU/OS were not notified directly despite the change being in effect.

@Sdrqaz Thanks for the poke - it led us to double-check internally, and we did in fact have an internal miscommunication that caused us to think we sent this email when we had not. We plan to send it out soon, and I just updated the Meta page to reflect a new deadline of June 3rd (2 more weeks).

Change #1153351 had a related patch set uploaded (by SBassett; author: SBassett):

[operations/mediawiki-config@master] Revert^2 "OATHAuth: Mark checkuser and suppress as requiring 2FA"

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

Change #1153351 merged by jenkins-bot:

[operations/mediawiki-config@master] Revert^2 "OATHAuth: Mark checkuser and suppress as requiring 2FA"

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

Mentioned in SAL (#wikimedia-operations) [2025-06-03T21:09:39Z] <mstyles@deploy1003> Started scap sync-world: Backport for [[gerrit:1153351|Revert^2 "OATHAuth: Mark checkuser and suppress as requiring 2FA" (T150898)]]

Mentioned in SAL (#wikimedia-operations) [2025-06-03T21:11:43Z] <mstyles@deploy1003> mstyles, sbassett: Backport for [[gerrit:1153351|Revert^2 "OATHAuth: Mark checkuser and suppress as requiring 2FA" (T150898)]] synced to the testservers (see https://wikitech.wikimedia.org/wiki/Mwdebug). Changes can now be verified there.

Mentioned in SAL (#wikimedia-operations) [2025-06-03T21:21:11Z] <mstyles@deploy1003> Finished scap sync-world: Backport for [[gerrit:1153351|Revert^2 "OATHAuth: Mark checkuser and suppress as requiring 2FA" (T150898)]] (duration: 11m 31s)