Page MenuHomePhabricator

Be able to force OATHAuth for certain user groups
Closed, ResolvedPublic

Assigned To
Authored By
Reedy
Nov 12 2016, 1:25 AM
Referenced Files
None
Tokens
"Pterodactyl" token, awarded by FriedrickMILBarbarossa."Love" token, awarded by Ejegg."Love" token, awarded by Pcoombe."Love" token, awarded by Ladsgroup."Love" token, awarded by Steinsplitter."Love" token, awarded by Framawiki.

Description

We need a way, for certain wikis to force certain users to use OATHAuth.

There are two (somewhat complimentary) possible approaches:

  • Refactor OATHAuth to use AuthManager for enabling/disabling (T137471), then write a SecondaryAuthenticationProvider that asks for 2FA to be set up after a successful login. (ResetPasswordSecondaryAuthenticationProvider is an example.) This is good when we want to completely lock users out of the wiki until they have set up 2FA but is less effective for already logged-in users who get promoted into a new user group (although the system could log them out when the promotion happens if they do not have 2FA set up).
  • Use the UserGetRights hook to disable sensitive permissions until 2FA is set up, and find some way to communicate to the user what is going on. This is good when we only want to require users with access to a certain permission to use 2FA, but the communication part seems messy (see T180888: All permission checks should be able to return a custom error message).

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes

Adding T&S since resetting these is presently a responsibility we've been taking on.

jrbs moved this task from Support to Radar on the Trust-and-Safety board.

Change 452020 had a related patch set uploaded (by MR70; owner: MR70):
[mediawiki/extensions/OATHAuth@master] Permissions of a specific groups should be removed if Two-Factor-Auth isn't enabled for a user

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

Reedy added a parent task: Restricted Task.Oct 27 2018, 8:56 AM
DStrine changed the visibility from "Public (No Login Required)" to "WMF-NDA (Project)".Oct 30 2018, 4:46 PM

@DStrine Why have you made the visibility restricted to WMF-NDA? I really cannot see any good reason for that

@Reedy it was previously set at a very restricted visibility setting. Are you suggesting restoring that?

DStrine changed the visibility from "Public (No Login Required)" to "WMF-NDA (Project)".

No it wasn't?

Reedy changed the visibility from "WMF-NDA (Project)" to "Public (No Login Required)".Oct 30 2018, 5:13 PM

After changing it back, I can view this task in incognito mode. We can't get much more open than that

It previously had the *custom policy at the top and was not visible my several WMF managers.

According to Phabricator it was Public, then you hid it:

DStrine changed the visibility from "Public (No Login Required)" to "WMF-NDA (Project)".Tue, Oct 30, 16:46

This task blocks multiple ones with restricted visibility, maybe this was causing confusion?

chasemp triaged this task as Medium priority.Dec 9 2019, 5:21 PM

The code seems to already have support for this. Can't we add rights with 2FA mandated to OATHExclusiveRights then?

The code seems to already have support for this. Can't we add rights with 2FA mandated to OATHExclusiveRights then?

It's not exactly the same. It's T199118: Degrade/temporarily remove user rights/groups if 2FA isn't enabled that was done, which is a similar, but different way to implement the same thing

It removes (temporarily( the rights if you don't have 2FA, but doesn't actually force you to enable it

On the other hand, if you're officially an interface admin, but don't have 2FA, as a result, you just can't do what IAs normally can. It does force you to enroll to 2FA if you want to enjoy the perks.

Well, suppressing rights is named in the task description as one of the possible ways to implement this task (although it's possible to do both ways at once, they are not exclusive). What's more problematic is

  1. Communication - apart from the message not being super useful (it should tell you where to go / what to do), it's not necessarily displayed (e.g. when the caller uses userCan). There should probably be some warning on the preferences page.
  2. Completeness - the UserGetRights hook is not implemented, so this only affects title-based permission checks, not userHasRight. How confident are we that the latter is never used for sensitive special page or log page access?
  3. Persistence - it's stored in the session; how long does that live? (I don't think it survives a browser restart.) How does it work for CentralAuth-based sessions? (Not at all, I'd guess.) Also, how does it work with things like OAuth or bot passwords? (Again, I don't think it works at all.)

Change 762385 had a related patch set uploaded (by Legoktm; author: Legoktm):

[mediawiki/extensions/OATHAuth@master] Require OATHAuth for membership in specified user groups

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

With the recent patch, I am curious about the following scenario:

  1. the oathauth-enable user right is only available to users in particular groups,
  2. all of those groups are listed in $wgOATHRequiredForGroups, and
  3. a user in one of these groups does not have 2FA enabled.

Will that user be stuck unable to enable 2FA because the oathauth-enable user right is only available via a group that is disabled because they don't have 2FA enabled?

That is a good point that I didn't think of, it'll definitely be an issue. Probably we need to still grant the oathauth-enable userright if a group membership is disabled for this reason.

PS4-5 fixes this by granting oathauth-enable whenever a user is in that situation. It doesn't actually check that one of the disabled groups granted it, but I think it is reasonable to expect that if a group is in $wgOATHRequiredForGroups, and a user is in that group, that they should be able to enable 2FA.

Thanks @Legoktm for working on this. One of the issues I see today in the "suppress group membership if 2FA is not enabled" is that it doesn't really make the account less privileged than they were before. Imagine I'm an interface administrator (a group that has mandatory 2FA), without having my 2FA enabled. This means I can't currently edit the site JS/CSS. However, any moment I want to edit site JS/CSS, I can just go ahead and enroll myself. An attacker can do the same thing, after acquiring access to my account.

Granted, since enrolling into 2FA requires a reauth, it means an attacker either needs to find a vulnerability in the reauth process that lets them to bypass it, or needs to know my password (to do the reauth dance). Purely having my cookies wouldn't give the attacker interface-admin access. However, accounts with 2FA enabled will work in the exact same way: just having my cookie jar will let you to do almost anything my account can do.

I recognize this is a disadvantage present in other forms of the same capability, and is not really an issue in @Legoktm's patch (which only prompted me to write this comment). For that reason, I don't have an issue with the patch getting merged as-is. However, before we enable the new feature in Wikimedia wikis, maybe we should discuss the aspect I described above?

Thanks @Legoktm for working on this. One of the issues I see today in the "suppress group membership if 2FA is not enabled" is that it doesn't really make the account less privileged than they were before. Imagine I'm an interface administrator (a group that has mandatory 2FA), without having my 2FA enabled. This means I can't currently edit the site JS/CSS. However, any moment I want to edit site JS/CSS, I can just go ahead and enroll myself. An attacker can do the same thing, after acquiring access to my account.

Yep, from an attacker's standpoint I don't think this *significantly* improves things security-wise. IMO the main issue right now is that there are legitimate reasons for a privileged account to temporarily have 2FA disabled, like if you're switching phones. Until we support having multiple 2FA methods being enabled at once (maybe the next project to work on ;)) we have to allow privileged users to remove their 2FA. What this will improve is that users will be constantly reminded that they need to re-enable 2FA because they can't do the actions they want to without doing that! I expect this will reduce the number of accounts that forget to re-enable 2FA and similar. Maybe in the future we don't allow granting privileged groups at all if you don't have 2FA, and if you disable your 2FA, your groups are automatically stripped and must be regranted? I haven't fully thought out the attack scenarios or UX for that yet. Either way, we're pretty far away.

Granted, since enrolling into 2FA requires a reauth, it means an attacker either needs to find a vulnerability in the reauth process that lets them to bypass it, or needs to know my password (to do the reauth dance). Purely having my cookies wouldn't give the attacker interface-admin access. However, accounts with 2FA enabled will work in the exact same way: just having my cookie jar will let you to do almost anything my account can do.

I think stealing cookies/sessions is an entirely separate threat that 2FA really doesn't protect against. There's another ticket somewhere about being able to list individual sessions and log them out as desired. In the meantime we're stuck with CA logging out every session when you log out in one place.

I recognize this is a disadvantage present in other forms of the same capability, and is not really an issue in @Legoktm's patch (which only prompted me to write this comment). For that reason, I don't have an issue with the patch getting merged as-is. However, before we enable the new feature in Wikimedia wikis, maybe we should discuss the aspect I described above?

Let me know if I didn't address your concerns fully. Mostly I think this should be seen as an incremental improvement, and not a solid wall that will entirely prevent privileged account compromises.

Two other points of my patch that might merit some discussion:

  • The API will leak whether someone has had groups disabled, and therefore doesn't have 2FA enabled. Do we need to close that before doing this?
  • Are we sure we want to do this at the group level and not rights level? Groups is IMO easier to communicate to users and how the policy is implemented, but then we will need a separate implementation for CA's global groups.

Change 762385 merged by jenkins-bot:

[mediawiki/extensions/OATHAuth@master] Require OATHAuth for membership in specified user groups

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

Change 763295 had a related patch set uploaded (by Reedy; author: Legoktm):

[mediawiki/extensions/OATHAuth@REL1_37] Require OATHAuth for membership in specified user groups

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

Change 763296 had a related patch set uploaded (by Reedy; author: Legoktm):

[mediawiki/extensions/OATHAuth@REL1_36] Require OATHAuth for membership in specified user groups

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

Change 763297 had a related patch set uploaded (by Reedy; author: Legoktm):

[mediawiki/extensions/OATHAuth@REL1_35] Require OATHAuth for membership in specified user groups

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

Change 763295 merged by jenkins-bot:

[mediawiki/extensions/OATHAuth@REL1_37] Require OATHAuth for membership in specified user groups

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

Change 763297 merged by jenkins-bot:

[mediawiki/extensions/OATHAuth@REL1_35] Require OATHAuth for membership in specified user groups

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

Change 763296 merged by jenkins-bot:

[mediawiki/extensions/OATHAuth@REL1_36] Require OATHAuth for membership in specified user groups

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