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.
- Mentioned In
- T282624: Limit IA granting/revoking to stewards only
T265726: Assign oathauth-verify-user to bureaucrats on WMF wikis
T251447: Assign oathauth-verify-user to stewards at metawiki
T250901: Allow privileged accounts to use action=query&meta=oath
T151010: Add logging to OATHAuth
- Mentioned Here
- T150562: Be able to force OATHAuth for certain user groups
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?
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
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.
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).
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.
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:
- Community determines access is allowed
- Community grants access (via crats and stewards)
- WMF audit at some interval
- 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).
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)?
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.
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))
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.
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
Based on rereading the above, going to
- Create Special:VerifyOATHForUser, a FormSpecialPage with a user field and a reason field
- similar to Special:DisableOATHForUser, the reason will be required
- Add oathauth-verify-user right to allow checking if a user has it enabled
- extension will provide this to the same groups that have oathauth-disable-for-user by default
- after deployment mediawiki configuration will be updated to remove the right from those groups
- after deployment it can be granted to the staff global group in the same manner as the oathauth-disable-for-user right
- If the user exists and is valid, report if they have it enabled
- When checking, add a log entry to oath/verify
- log visibility is restricted to users with oathauth-view-log
This does not result in any group having the rights on WMF production, unless access is added via global group management
Once the actual functionality is there we can discuss expanding access to eg stewards
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