Page MenuHomePhabricator

User right changes should require elevated security
Open, Needs TriagePublic

Description

Elevated security protects against account takeover via XSS; if an attacker can grant rights to an account it legitimately owns, that protection is lost.

This is true both for MediaWiki core (Special:Userrights) and global rights management extensions such as CentralAuth.

Event Timeline

Tgr created this task.Jun 13 2018, 4:43 PM
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptJun 13 2018, 4:43 PM

As someone who often changes user permissions locally and globally, requiring users to re-authenticate every time we need to change a permission would be overkill, at least from the perspective of the work we stewards do, and will lead to people using simple or easy passwords if they have to do this several times per day as it's our case (ie: something similar was argued not to force the users to change their passwords each Y days). Not that I'd use a weak password intentionally and put in danger the safety of our projects, nor my fellow stewards would do that of course; but it'd be quite annoying. Can we think of a different safety method? Please also note that changing userrights is always logged on Special:Log/rights so in principle weird changes of permissions can be quickly and easily spotted and reverted.

AIUI, as long as the permissions changes are within $wgReauthenticateTime of the last login you shouldn't be prompted again?

Tgr added a comment.Jun 13 2018, 5:53 PM

AIUI, as long as the permissions changes are within $wgReauthenticateTime of the last login you shouldn't be prompted again?

Yeah. There's a tradeoff here as on the one hand frequent reauthentication is annoying, on the other hand if someone does right changes a log and the timeout is long enough that they have elevated security most of the time, then it doesn't really offer any protection.

Thanks for the clarification :)

Rxy added a subscriber: Rxy.EditedJun 13 2018, 7:17 PM

I'm not sure, but If you assume this apply same logic as password change, must I input password and 2FA for each re-authorize? if that so, some one disable a 2FA IMHO. I like same logic as Google's implement. Also phabricator's high security mode. Current OATHAuth does not supplying option to bypass a prompt for "Trusted devices".

Vvjjkkii renamed this task from User right changes should require elevated security to x2aaaaaaaa.Jul 1 2018, 1:04 AM
Vvjjkkii triaged this task as High priority.
Vvjjkkii updated the task description. (Show Details)
Vvjjkkii removed subscribers: MarcoAurelio, Aklapper.
Ankry renamed this task from x2aaaaaaaa to User right changes should require elevated security.Jul 1 2018, 4:30 PM
Ankry raised the priority of this task from High to Needs Triage.
Ankry updated the task description. (Show Details)
Ankry added subscribers: MarcoAurelio, Aklapper.
revi added a subscriber: revi.Oct 20 2018, 3:17 AM

I'm not sure, but If you assume this apply same logic as password change, must I input password and 2FA for each re-authorize? if that so, some one disable a 2FA IMHO. I like same logic as Google's implement. Also phabricator's high security mode. Current OATHAuth does not supplying option to bypass a prompt for "Trusted devices".

I'd be that someone if 2FA is always forced on me every day — Stewards do make use of Special:UserRights every day or so, and being forced to enter 2FA every day — that would be too much disadvantage (I'll have to think of it as penalty) of using 2FA.

I've activated 2FA on phabricator and I already find that annoying. Let alone when I need to use that for user right changes and, even worse, for checkuser actions (T197158).

Tgr added a comment.Nov 6 2018, 1:07 AM

T197160#4723216 has some ideas on how to make this less annoying.

revi awarded a token.Feb 14 2019, 1:07 PM