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.

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).

In T209749#4801895, @Platonides wrote:

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.

In T209749#4801975, @MarcoAurelio wrote:

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.

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.

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).

Emailed T&S asking for any update.

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)?

In T209749#5028854, @Xaosflux wrote:

@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.

In T209749#5037299, @jrbs wrote:

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.

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

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?

In T209749#5101423, @Xaosflux wrote:

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.

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.

In T209749#5101631, @Tgr wrote:

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.

Noting we have this as an API (ApiQueryOATH) for this already, but nothing user focused...

The API call is protected by oathauth-api-all

Implementation should be some sort of Special:Page to view this status onwiki, and the API allows for this sort of querying for verification in third party systems if desired

We might need/want another separate right for doing that (and allow it on the API too), as oathauth-api-all can allow token validation via the other API module (ApiOATHValidate)... And while we want to allow one of those, we probably don't want to allow the validation arbitarily

Change 572402 had a related patch set uploaded (by DannyS712; owner: DannyS712):
[mediawiki/extensions/OATHAuth@master] Add Special:VerifyOATHForUser to check if users have OATH enabled

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

Change 579817 had a related patch set uploaded (by DannyS712; owner: DannyS712):
[operations/mediawiki-config@master] Preemptively revoke administrators' ability to check if 2FA is enabled

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

https://gerrit.wikimedia.org/r/#/c/mediawiki/extensions/OATHAuth/+/572402/ adds the functionality, and https://gerrit.wikimedia.org/r/#/c/operations/mediawiki-config/+/579817/ revokes it from admins, per discussion above.
After both are merged, no user group will have this right
It can be added to the staff global group via the onwiki interface

Change 579817 merged by jenkins-bot:
[operations/mediawiki-config@master] Preemptively revoke administrators' ability to check if 2FA is enabled

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

Mentioned in SAL (#wikimedia-operations) [2020-04-22T01:43:23Z] <reedy@deploy1001> Synchronized wmf-config/CommonSettings.php: T209749 (duration: 01m 01s)

Change 572402 merged by jenkins-bot:
[mediawiki/extensions/OATHAuth@master] Add Special:VerifyOATHForUser to check if users have OATH enabled

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

Change 596855 had a related patch set uploaded (by DannyS712; owner: DannyS712):
[mediawiki/extensions/OATHAuth@master] Add missing message verifyoathforuser

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

Change 596855 merged by jenkins-bot:
[mediawiki/extensions/OATHAuth@master] Add missing message verifyoathforuser

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