I suggest we push the conversation about who gets given this right on Wikimedia sites to a separate Wikimedia-Site-requests ticket created only after the OATHAuth extension is modified to allow for this to happen.

We have had several instances where

• people were still logged in, but knew that AFTER becoming logged out, they would loose access and were asking for password reset options.
• other trusted users were vouching for the identity of people

My idea was:

• Give people an interface to request a reset
• User needs to enter his name and password to initiate request
  • Check if user knows his password
  • Check if user has a verified email address
  • Check if verified email address and password were not changed recently (last 30 days?)
  • Log if user was still logged in when making the request
  • Log if request was initiated from 'known device'
• Now send the user an email with a reset token
• User needs to click the link+token in the received email
• Manual review by 'global' functionary
  • Functionary is provided with information on last log in, last edit, last activity, last email reset, date of request, if the user was logged in when he made request, and if that happened from a "known device"
  • Would do manual review of recent edit behavior
  • Possibly ask a checkuser to sign off on a reset request
• Functionary approves or declines
• Action of course noted in the logs

That to me would give a reasonable amount of certainty. while increasing overall security (having more people use 2FA). In my opinion, we need to recognize that people mess up sometimes. Most websites do.

IMHO even this is feature introducing some risk to users this should be as local as possible. For example I, as Czech Wikipedia administrator (medium wiki in size), I know quite a lot of very active (100+ edits/month) editors and can verify their request in various ways, including using chapter wiki, phone confirmation and of course, e-mail confirmation without using the Wikipedia interface. On the other hand, the stewards, althrough they are trusted at all wikis, do not know all the editors as well as the local editors.

As soon as login attempts (successful and unsuccessful) are logged in CheckUser, this should be the one responsible for reseting 2FA. I think that we can allow them to reset privileged accounts as well. For example, on Czech Wikipedia there are only a few of tech users who knows how to perform this kind of thing. Also, the developer with prod shell access may know the tech user but not the locked user themself. They can use some basic verifying method (mail) that is relatively easibly spoofable (sending an email from whatever address is easy technically) and trust the confirmation from the tech user. If this confirmation do for developer reset, why not move the responsibility too?

Of course, there are project without checkusers. Then, a steward should promote themself to this group, check recent login activity via CheckUser and require confirmation from bureaucrat or sysop policy-wise who will know the user more than the steward.

If we want, we can require at least two sign-offs, but I think that just one can do.

This is the problem with 2FA it supposed to be a system where the user needs something not digital to login a email account can be a hacked so if they manage to get a reset token mailed to them the physical aspect is away because there is now a digital access code in a email account which can be hacked. However it not viable to send a physical letter to every user who lost their 2FA. However for low-profile users without any additional permissions this is a option but its something you need to consider because its bound to in some way take away the physical aspect in my opinion we explicate state that if your lose your codes somehow your account is gone this of course would not apply to people who can physically ID themselves I.E an admin

I think we should consider a non-email, non-physical alternative too. Such as a security question. Or verification via text message.

Note that we don't need to keep their phone number in original form, we can encrypt it using a one-way hash; if they ever decide to disable 2FA via text message, they would have to provide their phone number again and we would be able to use the same one-way hash to verify it. Indeed, the answer to the security questions can (and should) also be stored using a one-way hash. The idea is to give the users a way to verify their identity, without us retaining any personal information on them, and without relying on email.

Do not use security questions. Finding my mother's maiden name, birth year or my dog's name is very easy novadays. Also, do not use phone itself, as it is used as 2FA device frequently. When I lost my phone, I usually lost SIM card too. Without SIM it is impossible to read the message.

I think we should reuse existing things from user commited identity over community relationships to locking account to ensure the account owner will notice.

We can also store copies of ID card for limited time for cases the request will be found as spoofed - then we can fill a lawsuit against the spoofer.

In T180896#4041445, @Huji wrote:

I think we should consider a non-email, non-physical alternative too. Such as a security question. Or verification via text message.

Note that we don't need to keep their phone number in original form, we can encrypt it using a one-way hash; if they ever decide to disable 2FA via text message, they would have to provide their phone number again and we would be able to use the same one-way hash to verify it. Indeed, the answer to the security questions can (and should) also be stored using a one-way hash. The idea is to give the users a way to verify their identity, without us retaining any personal information on them, and without relying on email.

There's been lots of cases of people hijacking phone numbers in order to get around SMS based 2fa. Using phone numbers is probably not the most secure thing.

Let's not go overboard and invent systems that no one will actually use. Reset requests are already happening. The goal of this task is to make them happen without taking up WMF staff time, not to come up with a new system.

In T180896#4039355, @Urbanecm wrote:

IMHO even this is feature introducing some risk to users this should be as local as possible.

There is no such thing as "local" when it comes to logins. Stewards should of course verify with the community of the user's home wiki that the request is legitimate (just like SuSa verifies it now).

The goal of this task is to make them happen without taking up WMF staff time

Well that should not happen. SuSa should continue to get involved. We cannot put this burden on volunteers and let them assume the liability of social engineering. I don't get paid, I'm not assuming the responsability here. There's also no such a thing "low-risk" accounts. Any account has the potential to become "high risk" by being promoted to higher user groups locally or globally. We've already got instances of socks waiting patiently and working hard to get elected to later cause as much havoc as they want. So no. This is a security feature. This is not the job of volunteers to assess if an account is compromised or not.

In T180896#4042795, @MarcoAurelio wrote:

SuSa should continue to get involved.

SuSa is already not necessarily involved; all the relevant documentation requires is to notify them after the fact (which could be automated if this was a software feature). But someone with shell access has to be involved currently, which is not the best use of shell user time (not a big deal right now, probably would get worse if 2FA became more widely available).

We cannot put this burden on volunteers and let them assume the liability of social engineering. I don't get paid, I'm not assuming the responsability here.

Do you mean some kind of legal liability? Otherwise, I cannot make any sense of it. The status quo is that low-risk accounts are not allowed to use 2FA at all, (in part) due to WMF staff support being unable to scale to that. Surely being able to use 2FA, with some tiny theoretical chance of of someone social-engineering through it, is better than not being able to use 2FA at all?

Also, 2FA reset is far less dangerous than other responsibilities that volunteers already routinely assume (such as vetting JS changes, or granting someone write access to site JS via the sysop bit).

Also, I doubt there is much difference in what a staff member and a volunteer can do in terms of assessing reset requests. There are roles where training and experience make a big difference, like dealing with harassment, but I don't think this is one of them. Whoever does the review would have to rely largely on the local community's judgement as to the reliability of the requester's identity, and beyond that just go through a simple checklist (make sure to send an email, make sure to wait X days etc). The local community would be the one that has to deal with social engineering attempts.

Any account has the potential to become "high risk" by being promoted to higher user groups locally or globally.

I don't think there is any credible threat scenario where someone uses a socially engineered 2FA reset to get access to an account and then waits until the account gets promoted to exploit it. Even if the legitimate owner does not read their emails, the credentials reset will log them out and they won't be able to log back again.

In T180896#4044927, @Tgr wrote:

Even if the legitimate owner does not read their emails, the credentials reset will log them out and they won't be able to log back again.

That's not actually the case, filed T189537: 2FA reset should log the user out.

Do you mean some kind of legal liability?

Yes I do. When I promote an user to sysop, the user account is the only responsible for their actions. I am just applying the community consensus. What the user does with their access is not my (legal) problem. If I am resetting a 2FA, I am being responsible of giving somebody access to an account that can be or cannot be theirs, unless I am misinterpretting how the process is going to be.

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.