Page MenuHomePhabricator

Deploy 2FA requirement using $wgRestrictedGroups to Wikimedia production, instead of OATHAuth's custom config
Open, Needs TriagePublic

Description

Currently, we require 2FA from four local groups CentralNotice administrators, checkusers, interface administrators, suppressors.

They are enforced using $wgOATHRequiredForGroups, which can disable the group membership for 2FA-less users. While it inclined most users of these groups to enable 2FA, a significant number of accounts has been left without 2FA. These accounts still pose a potential attack surface that could affect our other users.

To mitigate this, we'll switch to modern 2FA enforcement using $wgRestrictedGroups for these groups and additionally the following ones: Wikidata Staff, Wikifunctions Staff, WMF Office IT, WMF Trust & Safety.

The deployment for every group will happen in two stages, separated by about 2 weeks:

  • In the first stage, group members without 2FA will have their group membership disabled (as currently). Furthermore, it will be impossible to grant the group to a 2FA-less user. 2FA-enabled members of the group won't be able to completely disable 2FA on their account (they will still be able to add and remove 2FA methods, as long as there's at least one method continuously enabled). At this stage, the group will also be removed from $wgOATHRequiredForGroups.
  • After 2 weeks, in the second stage, group members without 2FA will be removed from the group. Nothing will change for users with 2FA enabled.

Nothing will change for users who are not members of the listed groups. For them, 2FA will still be optional. This change will enforce policy that's already been in force for as long as 7 years for some groups (and at least 10 months for others).

Deployment timeline

Deployments will usually happen at the beginning of the week

  • week of March 2nd: First stage for CentralNotice admins and WMF Trust & Safety
  • week of March 9th: First stage for the other 6 groups
  • week of March 16th: Second stage for CN admins and WMF T&S
  • week of March 23rd: Second stage for the other 6 groups

Event Timeline

group members without 2FA will be removed from the group

It seems to me that this is going to publicly reveal a list of accounts that have 2FA turned off. Most (perhaps all) of these accounts hold other advanced rights which do not require 2FA, yet are still powerful and potentially highly disruptive in the wrong hands (e.g. those in the sysop user group`). So this step will give malicious actors a list of accounts that may be easier targets, won't it?

I had always assumed the reason for the current setup, where users without 2FA enabled remain in the group but can't take advantage of its permissions, was because it doesn't disclose which accounts have 2FA and which do not.

group members without 2FA will be removed from the group

It seems to me that this is going to publicly reveal a list of accounts that have 2FA turned off. Most (perhaps all) of these accounts hold other advanced rights which do not require 2FA, yet are still powerful and potentially highly disruptive in the wrong hands (e.g. those in the sysop user group`). So this step will give malicious actors a list of accounts that may be easier targets, won't it?

I don’t think that’s a huge issue, there are countless of sysop accounts without 2FA. If that’s a concern, the solution would be requiring 2FA for sysops as well.

It’s certainly a higher security risk to stick to the current approach of just "deactivating“ CU/OS/IA permissions without removing the user from that group, given that attackers could just set up 2FA themselves to activate the permissions again once they've compromised such an account.

group members without 2FA will be removed from the group

It seems to me that this is going to publicly reveal a list of accounts that have 2FA turned off. Most (perhaps all) of these accounts hold other advanced rights which do not require 2FA, yet are still powerful and potentially highly disruptive in the wrong hands (e.g. those in the sysop user group`). So this step will give malicious actors a list of accounts that may be easier targets, won't it?

Yes, it will make it evident who out of then-former IAs, CUs etc. doesn't have 2FA. However, the group of users, who should have 2FA but don't have it, is dominated by interface administrators. Their activity is completely public (i.e. contributions to the MediaWiki: namespace). An attacker could already approximate who's likely not to have 2FA without us revealing the data. By degrouping the users, we'll make it a bit easier for the attacker, but on the other hand we'll massively reduce the potential damage (predominantly by abuse of interface administrator and CN admin).

It's worth noting that abuse of interface adminship can have potentially cross-project consequences, whereas for groups like administrator it will be reduced to a single project only (not good, but not terrible).

I had always assumed the reason for the current setup, where users without 2FA enabled remain in the group but can't take advantage of its permissions, was because it doesn't disclose which accounts have 2FA and which do not.

The main reason for the keeping the "disable group" approach in the last 10 months was that the OATHAuth extension (responsible for 2FA) supported only a single 2FA method at a time. It meant that users had legitimate reasons to disable 2FA on their account. It changed recently, after an overhaul of the extension code.

It’s certainly a higher security risk to stick to the current approach [...] given that attackers could just set up 2FA themselves to activate the permissions again once they've compromised such an account.

An attacker could already approximate who's likely not to have 2FA without us revealing the data.

These are both great points. Thanks for the thoughtful responses. It makes a lot more sense now.

Change #1247925 had a related patch set uploaded (by Mszwarc; author: Mszwarc):

[operations/mediawiki-config@master] Require 2FA from CentralNotice admins and WMF Trust & Safety

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

Change #1247925 merged by jenkins-bot:

[operations/mediawiki-config@master] Require 2FA from CentralNotice admins and WMF Trust & Safety

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

Mentioned in SAL (#wikimedia-operations) [2026-03-04T09:30:59Z] <mszwarc@deploy2002> Started scap sync-world: Backport for [[gerrit:1247925|Require 2FA from CentralNotice admins and WMF Trust & Safety (T418580 T417880)]]

Mentioned in SAL (#wikimedia-operations) [2026-03-04T09:33:05Z] <mszwarc@deploy2002> mszwarc: Backport for [[gerrit:1247925|Require 2FA from CentralNotice admins and WMF Trust & Safety (T418580 T417880)]] synced to the testservers (see https://wikitech.wikimedia.org/wiki/Mwdebug). Changes can now be verified there.

Mentioned in SAL (#wikimedia-operations) [2026-03-04T09:39:20Z] <mszwarc@deploy2002> Finished scap sync-world: Backport for [[gerrit:1247925|Require 2FA from CentralNotice admins and WMF Trust & Safety (T418580 T417880)]] (duration: 08m 23s)

Change #1247990 had a related patch set uploaded (by Mszwarc; author: Mszwarc):

[operations/mediawiki-config@master] Drop 'centralnoticeadmin' from $wgOATHRequiredForGroups

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

Change #1247990 merged by jenkins-bot:

[operations/mediawiki-config@master] Drop 'centralnoticeadmin' from $wgOATHRequiredForGroups

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

Mentioned in SAL (#wikimedia-operations) [2026-03-05T08:30:55Z] <mszwarc@deploy2002> Started scap sync-world: Backport for [[gerrit:1247990|Drop 'centralnoticeadmin' from $wgOATHRequiredForGroups (T418580)]]

Mentioned in SAL (#wikimedia-operations) [2026-03-05T08:33:02Z] <mszwarc@deploy2002> mszwarc: Backport for [[gerrit:1247990|Drop 'centralnoticeadmin' from $wgOATHRequiredForGroups (T418580)]] synced to the testservers (see https://wikitech.wikimedia.org/wiki/Mwdebug). Changes can now be verified there.

Mentioned in SAL (#wikimedia-operations) [2026-03-05T08:38:03Z] <mszwarc@deploy2002> Finished scap sync-world: Backport for [[gerrit:1247990|Drop 'centralnoticeadmin' from $wgOATHRequiredForGroups (T418580)]] (duration: 07m 07s)