editinterface in SUL means all admins, seems like. I've seen concerns that one can easily lose access to an account with 2FA and opposition towards making it mandatory for this and other reasons, so probably needs a consensus first.

I'm unconvinced

Wikitech accounts in general are fairly harmless. The danger there is taking over a developer account and adding SSH keys, I suppose.

I guess the blockers for this (beyond what's already captured in the task graph) are T180896: Allow functionaries to reset second factor on low-risk accounts and T150601: Add option to generate new set of recovery codes / T131788: Users should be notified when only two recovery codes are left? Is anything else considered necessary?

Well, on enWikipedia a few more issues have been raised:

• Not everybody has two devices available or is willing/able to pay for them.
• 2FA is not necessarily legal everywhere in the world.
• Not everybody can/will download an authenticator software in lieu of two devices, e.g when they are on devices they don't own.
• Technically complex. In my personal opinion, some folks who are tech savvy might be underestimating the complexity of such arrangements.
• The current system is prone to causing an account lockout.
• There are concerns of a slippery slope effect towards progressively less reasonable security measures.
• Only pertaining to sysop: Many people are not entirely convinced that the few instances of sysop accounts being taken over are worth these problems even if there were a solution for them.

In T150898#4805220, @JEumerus wrote:

• Not everybody has two devices available or is willing/able to pay for them.

2FA doesn't require two devices. A program to generate TOTP codes can likely be run on any device capable of running a web browser or the mobile apps. If necessary, there are even online password managers like https://keeweb.info/ that support TOTP. I further note that the software behind https://keeweb.info/ is open source, so you could run a mirror if you don't trust the site itself.

Of course, using one device or using a website does bring some reduction in security. It'll still be effective against the password reuse problem that seems to have been a major factor in the recent incident, at least until someone breaks into keeweb 🤷

• 2FA is not necessarily legal everywhere in the world.

The one comment on that enwiki discussion asserting this states "people who live in countries where it is not legal to own certain types of technology (or could result in significant state surveillance if owned)". It's not even clear whether that's referring to 2FA itself being illegal or just certain kinds of smartphones, or whether it is actually known to be illegal anywhere.

• Not everybody can/will download an authenticator software in lieu of two devices, e.g when they are on devices they don't own.

As noted above, there are websites that can do TOTP if you can't install an authenticator app.

Although I suppose some people might be opposed to doing that too. At some point there might need to be a cutoff for "don't want to".

• Technically complex. In my personal opinion, some folks who are tech savvy might be underestimating the complexity of such arrangements.

True, at least to some extent. Although for the mainstream use case it's pretty simple: install app, scan QR code, then copy 6 digits out of the app whenever you need to log in.

• The current system is prone to causing an account lockout.

Which is known and mitigating that is considered a blocker, see T150898#4802584.

• There are concerns of a slippery slope effect towards progressively less reasonable security measures.

Slippery slope arguments are themselves sometimes slippery slopes. Let's evaluate 2FA on its own merits.

• Only pertaining to sysop: Many people are not entirely convinced that the few instances of sysop accounts being taken over are worth these problems even if there were a solution for them.

On the other hand, many people are convinced. It's hard to get a feel for the sizes of these groups in the linked discussion because of people raising the other issues above instead. What we'd likely have to do there is address the blocking issues, prepare an RFC that clearly lays out options such as totp-me, desktop apps, and keeweb, and then somehow avoid pile-on from people who ignore that those other options exist.

Note there is a bit more discussion of requirements in the parent task (T166622).

IMO we might also want to rethink T150902: SMS based 2FA if we want 2FA to be deployed as widely as possible.

"As noted above, there are websites that can do TOTP if you can't install an authenticator app. Although I suppose some people might be opposed to doing that too. At some point there might need to be a cutoff for "don't want to"." Well yeah I'd expect that a lot of people don't want to trust a login that relies on a third party website/software, as they are often less than dependable & easy to use.

Perhaps, rather than "forcing" it for groups, restricted actions can run a hook that oath can intercept:

• Special:CheckUser and api - run CheckUserCanCheck - on wikis where oath is available, if the user doesn't have it enabled, say that they cannot run checks

@DannyS712 That sounds like T197501 or T201784

In T150898#5795848, @DannyS712 wrote:

Perhaps, rather than "forcing" it for groups, restricted actions can run a hook that oath can intercept:

• Special:CheckUser and api - run CheckUserCanCheck - on wikis where oath is available, if the user doesn't have it enabled, say that they cannot run checks

This is a really nice option in tandem with T197160: All security-sensitive MediaWiki functionality should require elevated security, it would be a natural way to create a "reauthentication with advanced privileges" boundary. I'm not sure we need any new hooks is we do this, most code will still call PermissionManager#userCan which would always compare using the currently-set permissions.

"Activate Special Privileges" or whatever we call the action that integrates with Extension:OATH might require a new hook, but that would be independent of any specific admin action. Once privileges are elevated (can include an optional expiration time), userCan matches against the new permissions.

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.