Page MenuHomePhabricator

Allow privileged accounts to determine if an account has enrolled in 2FA
Open, Stalled, Needs TriagePublic

Description

To support new office administrative policies that certain accesses should only be allowed on accounts using two factor authentication, an interface to allow bureaucrats and stewards to determine if an account has enrolled in two factor authentication should be provided such that this status can be validated prior to issuing restricted access.

Event Timeline

Xaosflux created this task.Nov 17 2018, 2:15 AM
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptNov 17 2018, 2:15 AM

I am not opposed to this idea, but I'd rather see the system automatically check itself if the user can use the rights once added to a group that requires enhaced security. I think it'd be even better, as it'd avoid people gaming the system having 2FA for when their promotion is going to happen, to disable it shortly afterwards. Does that make sense?

@MarcoAurelio agree - this should be best handled by the software, including downgrading access if un-enrolling from 2FA. It could be used to "audit" existing members periodically to ensure they have not removed it as well.

jrbs moved this task from Backlog to Support on the Trust-and-Safety board.Nov 20 2018, 10:59 PM

I'm assuming a 'mechanism' is already available for this in the API, and we are just be blocked by lack of access to :

(oathauth-api-all): Query and validate OATH information for self and others

I can only guess by the name of the new grant that such mechanism indeed exists as @Xaosflux said. But I guess they'll have to discuss whether this can be granted to others given that knowing if an account has or has not enhaced security is a socially sensitive feature I'd say.

Agree! Thus I was only asking for access to it to the groups charged with adding enhanced security accesses to accounts.

Tgr added a subscriber: Tgr.Dec 5 2018, 10:27 PM

oathauth-api-all will never be given to stewards, it's way too powerful. It only exists so the Toolforge admin panel can verify 2FA tokens. Adding another user right for the query part of the API would be trivial though.

This functionality would be pretty unpleasant in the hands of an attacker as it can be used to identify weak targets. Stewards already have access to plenty of things that are unpleasant when abused so that would probably not be a big change, but for bureaucrats (especially on small wikis) it would - their current powers are limited to a single a wiki, and users of that wiki, and this wouldn't be.

If $SECURITY_THEATER is needed for $RIGHT, then the software should not allow $RIGHT actions unless that is in use.

I think we should decline this task as worded.

Well it can certainly be reworded - I started this along the WMF requirements for 2FA for certain groups, in the absence of any technical controls that could do a better job. It could still be useful for stewards to be able to validate accounts before issuing other dangerous permissions (e.g. global sysop which gets int-admin on tons of projects).

I think we should decline this task as worded.

Perhaps add an oathauth-view right or something similar to provide read-only ability, as @Tgr suggested then?

It only exists so the Toolforge admin panel can verify 2FA tokens

Can you please clarify this? I'm not sure why Toolforge (a shared project with tools created and maintained by regular people) needs to access my 2FA tokens. I am sure I am confused here, but I'd be glad if this could be clarified. Thanks.

It only exists so the Toolforge admin panel can verify 2FA tokens

Can you please clarify this? I'm not sure why Toolforge (a shared project with tools created and maintained by regular people) needs to access my 2FA tokens. I am sure I am confused here, but I'd be glad if this could be clarified. Thanks.

I think they're referring to this: https://toolsadmin.wikimedia.org/

If my account has 2FA enabled (which it does), the site needs to be able to authenticate that code to log me in.

MarcoAurelio: https://toolsadmin.wikimedia.org/ is part of production services.

Tgr added a comment.Dec 6 2018, 1:09 AM

FWIW the account in question is the one on Wikitech (if only because it is hard to tie Cloud users to SUL identities, OTOH if Wikitech does get connected, we might just ditch the API and use OAuth instead). But yeah, oathauth-api-all is there to expose OATHAuth functionality to trusted production services, and won't be given to humans.

I may have misstated the name of the permission - but the overall concept has not changed - just looking for a way to determine a yes-no on a project as stop-gap while T150562 is being worked on. If I recall correctly the current workflow is:

  1. Community determines access is allowed
  2. Community grants access (via crats and stewards)
  3. WMF audit at some interval
  4. WMF undo's (2) for (3) failures

This would allow this whole process to stop at 2 for failure cases, and allow communities to self-audit.

Tgr changed the task status from Open to Stalled.Feb 2 2019, 10:08 PM
Tgr added a project: Security.

Needs approval from Security-Team or Trust-and-Safety.

Reedy added a subscriber: Reedy.Feb 5 2019, 7:14 PM

I note other tools/sites expose this to "administrators" and alike.

As such, hidden by a reasonably segregated userright, exposing this information in some form may be more useful for other MW sites that require this visibility without doing a database query (even if we decide we don't want to expose it on WMF sites).

Reedy renamed this task from allow bureaucrats and stewards to determine if an account has enrolled in two factor authentication to Allow privileged accounts to determine if an account has enrolled in 2FA.Feb 5 2019, 7:14 PM
revi added a subscriber: revi.Feb 28 2019, 7:03 PM
kolbert added a subscriber: kolbert.Mar 4 2019, 2:16 PM

Emailed T&S asking for any update.

jrbs added a subscriber: jrbs.Mar 15 2019, 7:15 PM

Thanks for the re-flag, @Xaosflux. Here's roughly where we, as the Trust and Safety team, stand on this:

In principle, we strongly support some form of automatically checking and continuously enforcing 2FA; both enforcing it on all functionaries who currently use this because it is required under policy, and allowing the community to check that an account really has enabled 2FA before granting it additional rights within the regular community process.

In practice, however, 2FA has larger issues that should be addressed first. We are looking into improvements for the 2FA tool as is, so these points will definitely be incorporated into that broader conversation. Thanks for raising them, and sorry for the delay.

@jrbs this specific task is only about the "allowing the community to check that an account really has enabled 2FA before granting it additional rights within the regular community process" part - so from a T&S point of view can it proceed (while not stopping any other types of improvement processes)?

jrbs added a comment.Mar 19 2019, 5:49 PM

@jrbs this specific task is only about the "allowing the community to check that an account really has enabled 2FA before granting it additional rights within the regular community process" part - so from a T&S point of view can it proceed (while not stopping any other types of improvement processes)?

I spoke about this with my team today. I'm not really in a position to make a final call on this, so take this with a grain of salt :)

It sounds like we would be supportive of a boolean value / indicator of some kind, viewable only by Stewards, which flagged something like "this user has met all technical requirements for access to advanced permissions" - some kind of collective, singular value covering everything from 2FA to NDA signature. This way, it is less obvious which accounts are missing 2FA, so in the extremely unlikely event a Steward account is compromised or goes rouge and goes fishing for accounts lacking 2FA, this is obscured in that the value may simply indicate they had not signed the appropriate NDA.

It's early days yet, and honestly I think this issue is quite low on the list of things that need to be addressed with the existing 2FA system, but that is where we stand on it.

Reedy added a comment.Mar 19 2019, 5:54 PM

It sounds like we would be supportive of a boolean value / indicator of some kind, viewable only by Stewards, which flagged something like "this user has met all technical requirements for access to advanced permissions" - some kind of collective, singular value covering everything from 2FA to NDA signature. This way, it is less obvious which accounts are missing 2FA, so in the extremely unlikely event a Steward account is compromised or goes rouge and goes fishing for accounts lacking 2FA, this is obscured in that the value may simply indicate they had not signed the appropriate NDA.

And something to possibly tie into T150562: Be able to force OATHAuth for certain user groups

Thanks for the update @jrbs so for those of us that give out int-admin locally, we'll just keep saying "you better do this" and leave it up to WMF to enforces the 2FA rules.

RhinosF1 added a comment.EditedApr 10 2019, 3:41 PM

I think a message that says 'This accounts meets the minimum standards for Account security' is sufficient with it maybe revealing which points failed to highly trusted users or maybe just staff.

I'd want data to be kept for at least a week or so in case of compromise so it can be checked if they met standards at the time of compromise.

I'd even support the software treating it as if the Account didn't have rights that require certain security standards (although excluding 2FA from this as some people have issues with it (I've had no issues since enabling it last night))

Cross post from https://en.wikipedia.org/wiki/Wikipedia_talk:Arbitration_Committee/Noticeboard#Return_of_permissions_for_compromised_administrator_accounts

Izno added a subscriber: Izno.Apr 10 2019, 3:43 PM

If this becomes a 'This accounts meets the minimum standards for Account security' checker, then perhaps it should also have an expanded output if run on 'self' - declaring what components you are missing so you know what you need to remediate?

If this becomes a 'This accounts meets the minimum standards for Account security' checker, then perhaps it should also have an expanded output if run on 'self' - declaring what components you are missing so you know what you need to remediate?

Letting users know when they fail standards should be done by a tick box at the 2FA and password change boxes on preferences and via a notification with information being expanded on in a pop up when clicking on the status or maybe on a new special page.

I'd expect it to be viewable by those with the userrights permission only for other users obviously so hackers can't find weak accounts easily.

Tgr added a comment.Apr 10 2019, 4:22 PM

There's no way to check someone's password without having them enter it, so if you want to turn this into a more generic account security check (which would presumably cover password policies + 2FA as there's not much else we can check - a check for not loading unsafe Javascript would be nice but probably not feasible) that'd probably have to be some kind of private log where the user can add an entry by reauthenticating.

There's no way to check someone's password without having them enter it, so if you want to turn this into a more generic account security check (which would presumably cover password policies + 2FA as there's not much else we can check - a check for not loading unsafe Javascript would be nice but probably not feasible) that'd probably have to be some kind of private log where the user can add an entry by reauthenticating.

@Tgr, Maybe the check should be done at the time the password is set against everything with them forced to rerun the check when the comman password lists are updated.

Base added a subscriber: Base.Apr 29 2019, 9:41 PM