Change 501964 had a related patch set uploaded (by Ladsgroup; owner: Ladsgroup):
[mediawiki/extensions/OATHAuth@master] Add private logging when user disables 2fa for someone else

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

Change 501964 merged by jenkins-bot:
[mediawiki/extensions/OATHAuth@master] Add private logging when user disables 2fa for someone else

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

In T180896#5106994, @gerritbot wrote:

Change 501964 merged by jenkins-bot:
[mediawiki/extensions/OATHAuth@master] Add private logging when user disables 2fa for someone else

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

There was a comment in the patch - "It's better that we add for when someone enables or disables for self too But that can be done in a follow-up patch"
Is such logging still desired? If so I can submit a patch

How this can be moved forward? Now there is a special page that actually has logs for disabling 2FA. The first step would be to enable it for WMF T&S user group (if such group exists) so they at least don't need to ssh to production for this (otherwise, everything stays the same). Does that sound good?

There's indeed a wmf-supportsafety local group on Meta Wiki (local page) that is assigned to all T&S employees. Regards.

Change 650988 had a related patch set uploaded (by Urbanecm; owner: Urbanecm):
[operations/mediawiki-config@master] Grant oathauth-disable-for-user and oathauth-verify-user to wmf-supportsafety at Meta

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

Uploaded a patch to that effect. I also added oathauth-verify-user to that group, as I discussed that with T&S off-Phab some time ago.

Currently the functionality is not limited to low-risk accounts, nor does it warn when the account is high-risk. I think that would be nice to get done first. See T208477: Move "privileged account' concept into MediaWiki core.

True, through my patch is mildly related to this topic. It is also in line with T&S current duties (they use the maint script for removing 2FA now).

Change 650988 merged by jenkins-bot:
[operations/mediawiki-config@master] Grant several OATHAuth-related permissions to wmf-supportsafety at Meta

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

Mentioned in SAL (#wikimedia-operations) [2021-01-04T12:08:05Z] <ladsgroup@deploy1001> Synchronized wmf-config/InitialiseSettings.php: [[gerrit:650988|Grant several OATHAuth-related permissions to wmf-supportsafety at Meta (T180896)]] (duration: 00m 56s)

In T180896#6705165, @Tgr wrote:

Currently the functionality is not limited to low-risk accounts, nor does it warn when the account is high-risk. I think that would be nice to get done first. See T208477: Move "privileged account' concept into MediaWiki core.

Resetting 2FA doesn't happen that often, we can simply ask stewards not to do it for high-risk accounts and leave it to WMF CA (and I trust stewards not to do it). It would eliminate lots of technical work for this while unblocking an important security feature.

Hello security team, T&S is fine with letting stewards handle low-risk accounts and escalating privileged users to T&S but they need security team's approval to move this forward. Would that work?

What counts as a low risk account? Or the reverse, what rights/groups are going to mark an account as not "low risk"? Are we going to put any technical controls in to prevent this being done accidentally?

What process is going to be used to confirm identity?

In T180896#6792396, @Reedy wrote:

What counts as a low risk account? Or the reverse, what rights/groups are going to mark an account as not "low risk"?

My understanding is this would be accounts with rights lesser than sysop (e.g. no privs, or privs like rollback / autoconfirmed). Sysop or higher would require the usual process.

Right.

While we don't need a policy... We kinda do need a policy (informal, not a WMF policy particularly) to codify this stuff. And *maybe* technical controls to prevent it where applicable. Maybe.

Rather than having confusion/grey areas down the line :)

There's obviously groups like Interface Editors/Admin (whatever we're calling it these days), which may not be sysop, should probably be included, as you can definitely do some damage with those rights

Any role where 2FA is required should be excluded.

We do already have a list of "privileged groups" where a non-default password policy is defined.

'wmgPrivilegedGroups' => [
	// Default should include any privileged group on any SUL wiki. Ideally we'd check for all wikis memberships on that wiki vs. wmgPrivilegedGroups for that wiki, but
	// we can only check memberships on a non-current wiki, not config, so we need to mash everything together here.
	'default' => [
		// core or extension groups
		'bureaucrat', 'checkuser', 'interface-admin', 'oauthadmin', 'oversight',  'sysop',
		// custom groups used on several wikis
		'arbcom', 'botadmin', 'eliminator', 'import', 'interface-editor', 'transwiki',
		// custom groups used on one or a few wikis
		'abusefilter' /* enwiki */, 'curator' /* enwikiversity */, 'engineer' /* cswiki, ruwiki */, 'facilitator' /* frwikinews */, 'founder' /* enwiki */, 'templateeditor' /* rowiki */, 'test-sysop' /* betawikiversity, incubatorwiki */, 'translator' /* incubatorwiki */, 'wikidata-staff',
		// metawiki local groups with global powers (some also on testwiki)
		'centralnoticeadmin', 'global-renamer', 'translationadmin', 'wmf-officeit', 'wmf-supportsafety',
		// wikitech local groups with global powers
		'cloudadmin', 'oathauth',
	],
	'+fishbowl' => [ 'user' ],
	'+private' => [ 'user' ],
],
'wmgPrivilegedGlobalGroups' => [
	'default' => [ 'abusefilter-helper', 'founder', 'global-deleter', 'global-interface-editor', 'global-sysop', 'new-wikis-importer', 'ombudsman', 'staff', 'steward', 'sysadmin', 'wmf-researcher' ],
],

That seems like a sensible starting point.

Enforcing it would be complicated but I can write a gadget for stewards to warn them if they are disabling an account that has a privileged right in a wiki. Would that be enough?

That being said, currently most users can't enable 2FA unless they are at least admin somewhere making this basically useless except for rare edge cases of 2fa testers and people who lost their rights (unless we open it to everyone or maybe autoconfirmed users?)

Just provide a hook or other callback point and make it call wfGetPrivilegedGroups(). Or do the same by implementing T208477.

In T180896#6793698, @Ladsgroup wrote:

That being said, currently most users can't enable 2FA unless they are at least admin somewhere making this basically useless except for rare edge cases of 2fa testers and people who lost their rights (unless we open it to everyone or maybe autoconfirmed users?)

The 2FA tester group seems to be very freely given out. There was a request in the last few weeks of a basically brand new account (few to no edits) that had recieved it, and had already locked themselves out...

And obviously at some point, we do want to allow everyone to enable 2FA - T166622: Allow all users on all wikis to use OATHAuth

In T180896#6793634, @AntiCompositeNumber wrote:

We do already have a list of "privileged groups" where a non-default password policy is defined.

Indeed. But at the same time, no one had said in this task what was going to be used for this purpose. It's worthwhile to be clear and explicit so expectations can be set.

In T180896#6793848, @Tgr wrote:

Just provide a hook or other callback point and make it call wfGetPrivilegedGroups(). Or do the same by implementing T208477.

I see T208477 seemingly stalled from lack of CR. Hmm.

Obviously it needs some sort of check for a list of groups (staff and/or sysadmin.. Or even just wmf-supportsafety) who can still do it, along with still allowing it via shell obviously.

Part of the point of this task is that it may be a blocking capability to wide spread rollout.

The underlying solution is technically solved, and these operations are now able to be done on-wiki, with logged - by those with access. However the only "functionaries" authorized are WMF support.

So should WMF decide to relegate this to volunteers, a site-configuration (for local projects) or steward action (global groups) could do this now. Such would currently be blocked for non-technical reasons.

site-configuration (for local projects)

If this is chosen we may still want a technical measure preventing them from remove 2FA from users with advanced right.

steward action (global groups)

If we decide only stewards can do so, then we may want 2FA reset only used in Meta. This then requires a configuration change of meta local steward group.

OK good point, so more tech work to do. Right now the access allows targeting anyone. It would need to be split, with 2 different permissions (r.g. remove, remove-high-security-user)

If this is chosen we may still want a technical measure preventing them from remove 2FA from users with advanced right.

More likely, there would just be no mechanism to remove 2FA from users with advanced rights. Instead, you would have to remove the advanced rights from the user entirely (at least the rights that enforce a 2FA requirement), and then disable 2FA from that user. That is both more secure, and keeps the permission structure simpler.

In T180896#11439152, @EMill-WMF wrote:

If this is chosen we may still want a technical measure preventing them from remove 2FA from users with advanced right.

More likely, there would just be no mechanism to remove 2FA from users with advanced rights. Instead, you would have to remove the advanced rights from the user entirely (at least the rights that enforce a 2FA requirement), and then disable 2FA from that user. That is both more secure, and keeps the permission structure simpler.

Though WMF SuSa currently can remove 2FA from a steward.

I am wondering whether this could be something to just deal with with some suitable policy for stewards using the feature rather than a technical restriction. If there is good logging of such operations in place, at least.
For a broader rollout, this may be less suitable.