If we make too many things require reauth then we run the risk of annoying users. We also run the risk of making entering your password a common occurance which could aid phising attacks

Would it be possible to, instead of asking users for their password, ask them to enter another 2FA token? As in, reauth them via 2FA? That way, they won't input their password, what they enter is different each time, what they enter is something only they can access, and the annoyance level is probably much less.

In T197160#4281157, @Bawolff wrote:

If we make too many things require reauth then we run the risk of annoying users.

Yes, based on comments on other tasks that is clearly a problem. It can be reduced by making reauth less annoying - T197153: Make some providers optional for reauthentication will skip the first stage of the login form, T100373: WebAuthn (U2F) integration for Extension:OATHAuth will reduce the second stage to a single touch if you have a hardware token or you are using a phone or laptop with a fingerprint reader. (With WebAuthn face detection is also possible in theory. Not sure how reliable that is; you can't exactly keep your face secret.)

I outlined some ideas in T208823: Support asynchronous reauthentication on making it even less annoying.

We also run the risk of making entering your password a common occurance which could aid phising attacks

That will be solved by T208668: Do not ask for password on reauthentication when 2FA is enabled.
Arguably asking frequently for the second factor still aids phishing somewhat, but 1) the attacker has to obtain the password in a different way, at least, 2) the second factor is is much more restricted (limited lifetime, single-use), 3) once we support T100373: WebAuthn (U2F) integration for Extension:OATHAuth it will be possible to have unphishable second factor.

This should be a list of rights that require having been authenticated less than <configurable> minutes ago, which would allow us to change which rights need an "elevated security". We should also allow configuring the suitable providers, so an account could login and edit without 2FA, need a TOTP token for a CheckUser, and creating a sysop would require using the hardware token that is stored in the dungeon safe, watched by lots of guards and crocodiles.

However, when we wanted the user to reauthenticate, we would need to show the user a proper form, rather than have userCan() simply fail. Technically, it might be possible to have userCan throw a special exception if the request can succeed through an extra token, and catch it at high level, ut seems clumsy. And also, userCan is used liberally, even in cases where we would not want to force a reauthentication...

Two things come to mind. First, even if we *only* require people with admin or higher permissions/private wikis/etc, we're talking over 5000 users who would require 2FA. This number of users would require the WMF to have dedicated resources available 24/7 to assist users who get locked out of their accounts due to some sort of systemic or user issue. That's a minimum of 5 FTE whose "drop everything and do it now" job would be dealing with 2FA failures, although obviously they could be doing other things too. I'm well aware that WMF staff developers are already overloaded with real and potential tasks, so I'm concerned that it would mean additional staffing. There are less weighty steps that can be taken first (e.g., the planned changes in password requirements, socialization to the use of previously unused passwords unique to the Wikimedia SUL account, etc.).

The second is that we have over 35 million user accounts. I put that out there now because the vast majority of compromised accounts are not "privileged", and the amount of support required to even give access to 2FA for that group would be really huge. Even if only the most active 30K accounts use it, that's still not targeting the accounts most likely to be compromised. Again, socialization to improved personal account security will help for currently active users, but most compromised accounts have not had a log-in for months to years.

In T197160#4801750, @Platonides wrote:

This should be a list of rights that require having been authenticated less than <configurable> minutes ago, which would allow us to change which rights need an "elevated security".

That is how $wgReauthenticateTime works.

We should also allow configuring the suitable providers, so an account could login and edit without 2FA, need a TOTP token for a CheckUser, and creating a sysop would require using the hardware token that is stored in the dungeon safe, watched by lots of guards and crocodiles.

That is blocked on T197153 (which is turning out to be way more trouble than I anticipated).

However, when we wanted the user to reauthenticate, we would need to show the user a proper form, rather than have userCan() simply fail. Technically, it might be possible to have userCan throw a special exception if the request can succeed through an extra token, and catch it at high level, ut seems clumsy. And also, userCan is used liberally, even in cases where we would not want to force a reauthentication...

That's T197136: Tie certain user rights to elevated security. Currently reaut check is done by the special page / API, and is not integrated into the permission system, which is not ideal but work (and we are stuck with it short of a refactoring, although that might happen due to T208768), so this is not currently a problem.

In T197160#4802458, @Risker wrote:

First, even if we *only* require people with admin or higher permissions/private wikis/etc, we're talking over 5000 users who would require 2FA.

Note this task is about elevated-security reauthentication (see also T197130: Document MediaWiki elevated security feature :), not enabling 2FA for everyone (that's T166622: Allow all users on all wikis to use OATHAuth) or mandating it for some to-be-determined set of user groups (T150898: Force OATHAuth (2FA) for certain user groups in Wikimedia production); reauthentication can be a normal password check.