Bureaucrats on WMF wiki's are given the ability to issue interface administrator access to other users, and WMF has required that holders of this group have 2FA enabled. This access will allow these groups to ensure that the foundation requirements are met before performing that action.
This tool was created in T209749, see similar permission rollout in T251447
| Subject | Repo | Branch | Lines +/- | |
|---|---|---|---|---|
| InitialiseSettings.php: Add oathauth-verify-user to default bureaucrat | operations/mediawiki-config | master | +1 -0 |
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Declined | None | T265726 Assign oathauth-verify-user to bureaucrats on WMF wikis | |||
| Declined | None | T282624 Limit IA granting/revoking to stewards only |
Somewhat expect this to be controversial and need some weigh in. One the one hand, there is no way for these users to ensure this is in place before extending sensitive access - on the other hand some projects have a staggering amount of bureaucrats for some reason that this would extend the query access to (e.g. eswiki has 68 crats!). I'd say only on projects where bureaucrats can issues interface-admin, but that is currently all of the projects.
As the WMF-Legal project tag was added to this task, some general information to avoid wrong expectations:
Please note that public tasks in Wikimedia Phabricator are in general not a place where to expect feedback from the Legal Team of the Wikimedia Foundation due to the scope of the team and/or nature of legal topics. See the project tag description.
Please see https://meta.wikimedia.org/wiki/Legal for when and how to contact the Legal Team. Thanks!
Please see https://meta.wikimedia.org/wiki/Legal for when and how to contact the Legal Team
Has anyone left them a message?
2FA logins are global, so this would mean someone taking over an xywiki bureaucrat account could check which valuable accounts on large wikis are easy targets. Once T150898: Force OATHAuth (2FA) for certain user groups in Wikimedia production gets enforced, that might be an acceptable risk, as account takeover is not terribly damaging for non-sensitive accounts; for now, I'm not sure it is a good idea.
@Tgr - we also allow all those 'crats to issue int-admin to anyone - but they are not supposed to do it unless the accounts have 2FA -- but they aren't able to actually check that so they just give it to anyone that claims they have 2FA, defeating the control (also not allowing audit to see if 2FA has been disabled). I expected this to be a bit borderline due to the way some projects (such as eswiki I mentioned above) give out 'crat to lots of users.
I suppose being able to make others into interface admin is already dangerous enough that 2FA checks do not add much risk; but the former has a public audit trail which makes abusing it much more difficult. How are 2FA checks logged?
Change 835252 had a related patch set uploaded (by Samtar; author: Samtar):
[operations/mediawiki-config@master] InitialiseSettings.php: Add oathauth-verify-user to default bureaucrat
Change 835252 abandoned by Samtar:
[operations/mediawiki-config@master] InitialiseSettings.php: Add oathauth-verify-user to default bureaucrat
Reason:
Legal: NDA issue, see task
WMF Legal got back to me. They said that "account's 2FA status would constitute non-public personal information". This means that this level of access cannot be granted to bureaucrats, as they aren't necessarily under an NDA. Setting the status to Declined.
Thanks for the note; so seems like this could be done to a group that already requires NDA - such as oversighters or checkusers, correct?
Of course the initial problem of: bureaucrats assign access that requires 2FA, but aren't able to validate 2FA isn't directly solved even with that. (Unless only Crats that are also CU/OS were doing this)
The ruling that 2FA status is "non-public personal information" doesn't make sense to me. How is it any more non-public than than "has an email address set"? For reference, the email address status is exposed to anyone with an account and verified email address via Special:EmailUser (attempting to email a user without an email set will get the error This user has not specified a valid email address.). Further, the 2FA group requests take place on a public noticeboard (https://meta.wikimedia.org/wiki/Steward_requests/Global_permissions), a steward confirms that they have added the oauth-tester group, and the group membership is public. As possible attack vectors go, one can have a fairly good chance at identifying 2fa users by membership in said group or lack thereof. Or if someone requests intadmin but doesn't have 2FA set...the stewards will most likely say something to the effect of "sorry, we can't grant this until you turn on 2FA," won't they? Or will they have to give vague decline reasons if someone refuses to enable it?
@GeneralNotability: if NDA is not required, that means we would be able to make a list of people that do and don't have 2FA enabled and release it freely, increasing the attack probability for those users. OTOH, group membership doesn't mean 100% that the user has 2FA enabled, and even if the user has IA somewhere, it's not guaranteed that they do have it enabled, even though it's required. The way it currently is seems the safest to me, only a few privileged users (obligatory disclaimer: of which I'm part of) have access to that, and it is logged so that any other steward or WMF staff can verify what they're doing. Furthermore, the difference between emails and 2FA is (among other things) that 2FA enrollment is only queryable by stewards/staff/sysadmins, all of which have mandatory NDAs.
You're arguing that this information is security-relevant. That is not the same thing as "non-public personal information". I'm absolutely being an armchair lawyer here, but the privacy policy is pretty clear that it applies to information which could be used to identify you. There is no PII contained in the one-bit "2FA enabled" / "2FA disabled" setting, and that's a significant part of my objection.
And yes, a malicious actor could release the 2FA list, and yes, that could be used to identify easier users to attack. It indicates more vulnerable users, but does not itself constitute an attack vector. I argue that that is a very low-probability risk, given that (as far as I know) all 'crats will have already met the community-review standards for adminship. These are people who, by and large, aren't dumping deleted articles onto the Internet or leaking abuse filters. Also, a steward could release that information just as easily as a local 'crat, and before Legal's response today that wouldn't have even been a clear-cut reason to revoke said steward's NDA. And - once again - what happens if a steward has to say "sorry, we can't grant you IA because you don't have 2FA enabled" or "we will not grant this user IA because they have refused to meet the security standards"? According to the above, that's an NDA breach, but that's kind of ridiculous.
Furthermore, the difference between emails and 2FA is (among other things) that 2FA enrollment is only queryable by stewards/staff/sysadmins, all of which have mandatory NDAs.
That's rather circular, isn't it? The fact that something is currently only accessible to people who have signed the NDA does not inherently mean that that thing is NDA-protected.
Note: According to Data retention guidelines, account settings belong to Non Public Personal information. Thanks.
Huh. I had not seen that particular document, would have been nice if it had been mentioned in the privacy policy. Thanks @SCP-2000.
Hi folks, just want to add a note from WMF Legal since we're looking at this. We do think as Urbanecm relayed, that this info is personal data, and the discussion here already is correct in how to think about it. On GeneralNotability's point, we are planning to take a review over the privacy policy in the next couple years ("couple" used loosely here, we don't have a firm date yet) and can take this point into account as we update. I think what counts as personal info in various laws around the world has updated quite a bit in the last few years. Also as a general note, I at least am of the opinion that 2FA is good and helpful overall, even with problems it can cause. So if various legal and policy issues do cause significant disruption to the ability of folks to set it up, please let us know and we'll focus on finding ways to improve the situation.
@Jrogers-WMF what spawned this is that WMF wants certain accounts to have 2FA enabled (e.g. interface admins); however the groups that give this out (e.g. bureaucrats) can't check if this is in place, or ensure it is left enrolled. Is the only block from WMF that this check tool should only be available to users that have enrolled in the NDA process, if so perhaps a different existing group (e.g. checkusers) could be leveraged?
This might work as a solution to this problem, since CUs (or even OSes) should already be covered by appropriate NDAs or similar agreements. If they could support those additional workloads, of course. But there is a secondary issue (as discussed a bit above) about the 2fa status of users being considered non-public data which would substantially hinder certain on-wiki processes, such as confirming 2fa status with various users, which happens publicly in many cases right now, AIUI.
Change 835252 restored by Samtar:
[operations/mediawiki-config@master] InitialiseSettings.php: Add oathauth-verify-user to default bureaucrat
Change 835252 abandoned by Samtar:
[operations/mediawiki-config@master] InitialiseSettings.php: Add oathauth-verify-user to default bureaucrat
Reason: