It was recently suggested on #wikimedia-commons that users without 2FA enabled should automatically have checkuser (And maybe oversight, and eventually maybe admin) rights disabled, and then automatically enabled once they re-enable 2FA.
We should consider looking into this.
See the (private) task T197500 for a list of users this would affect.
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Restricted Task | |||||
| Open | None | T150898 Force OATHAuth (2FA) for certain user groups in Wikimedia production and Beta wikis | |||
| Declined | None | T197501 Make users without 2FA setup not have checkuser right regardless of their groups | |||
| Resolved | mszwarc | T150562 Be able to force OATHAuth for certain user groups |
@Bawolff from what I understand, the way CheckUser works right now is it calls checkPermissions which is inherited from SpecialPage. I am thinking we can override this method in which we first call the parent function, and then call a hook (and I need your suggestion for its name, does onCUCheckPermission sound good?) to allow other extensions to control whether the method results in a pass or a fail situation. Finally, we can modify #OATHAuth code to return a pass if the user has 2FA enabled and fail otherwise.
I think the limitation here is what @Reedy mentioned in T150562 i.e. the communication piece will be messy (as in, the user will get a generic permission error, not one that specifically says "you need to enable 2FA"). Unless there is a way to avoid that which I am not able to think of.
If we do do this bug - I think the 2FA system should hook into mediawikis auth system directly - not try and override how checkuser works. E.g. use the userCan hook or UserGetRights hook or some similar hook.
Change 450292 had a related patch set uploaded (by MR70; owner: MR70):
[mediawiki/extensions/CheckUser@master] Bug: T197501
Change 450293 had a related patch set uploaded (by MR70; owner: MR70):
[mediawiki/core@master] Bug: T197501
It was pointed out to me that this might not be the best idea, because if an attacker compromises an account that has temporarily removed 2FA, the attacker can just enroll into 2FA to get back access.
Unlike interface-admin, there is currently no policy that requires checkuser to have 2FA enabled. Such a policy should be implemented before we enforce it.
Product Safety and Integrity takes an approach to roll out 2FA enforcement based on the user's groups and closely tied to the actual membership in these groups (for CUs it was done in T418580). One of the reasons is the issue quoted above. For that reason, we won't implement rights-based 2FA enforcement.
As of now, it's the site administrator's responsibility to have a groups/rights/enforcement combination that makes sense (i.e. no checkuser-capable groups with no enforcement). A safeguard similar to only interface admins having code-editing rights may be helpful, but that's out of scope of this request.