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 and Beta wikis); reauthentication can be a normal password check.

In T197160#4281158, @Bawolff wrote:

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

@Bawolff 's point is entirely valid, and was even more so when it was written 8 years ago. But...

In a previous job, the setup was that 2FA was via a Yubikey. We had those cute little things that plugged into a USB-A port and just had a nubbin sticking out. One lived in a port on my laptop all the time so re-authing was as simple as reaching out with a fingertip and tapping. Now we're in 2026 and this sort of tech has become ubiquitous even on consumer-level hardware. Right now, I'm working on my personal machine with Touch-ID, so basically the same setup.

Standardizing on this sort of hardware 2FA seems like a reasonable approach. I can see how somebody might push back on having to open their phone, run some app, and manually copy 6 digits to the keyboard every time. But I really can't see how anybody could reasonably object to a fingertip tap. Many users with advanced permissions (say, CU, OS, IA, Steward) will already have this tech available. And for the few who don't, buying them a (for example) $150 Apple Magic Keyboard really should fall into the budget category of "too little to worry about".

There will undoubtedly be some small number of people for whom compliance with this will be impractical because of where they live, disabilities, etc. Deal with the exceptions as they come up but don't let that stand in the way of the larger picture.

But I really can't see how anybody could reasonably object to a fingertip tap. Many users with advanced permissions (say, CU, OS, IA, Steward) will already have this tech available. And for the few who don't, buying them a (for example) $150 Apple Magic Keyboard really should fall into the budget category of "too little to worry about".

I don't understand how having certain permissions (CU, OS, IA, Steward) and owning a hardware token are related; in my opinion, these are completely unrelated things.

There is a very technically competent user in ruwiki, whose monthly income is $160. (He is disabled person and receives a disability pension.)

In T197160#11684598, @MBH wrote:

But I really can't see how anybody could reasonably object to a fingertip tap. Many users with advanced permissions (say, CU, OS, IA, Steward) will already have this tech available. And for the few who don't, buying them a (for example) $150 Apple Magic Keyboard really should fall into the budget category of "too little to worry about".

I don't understand how having certain permissions (CU, OS, IA, Steward) and owning a hardware token are related; in my opinion, these are completely unrelated things.

There is a very technically competent user in ruwiki, whose monthly income is $160. (He is disabled person and receives a disability pension.)

Note even certain group requiring 2FA, we do not limit the way to implement it. There are browser extensions and desktop apps acting as 2FA clients. Of course using 2FA client in your computer is less secure, but it is an acceptable solution.

Yubikey's are very cheap, especially when buying in bulk. I think we'd be talking like $15 each. One potential option is that WMF just buys a yubikey for every person with intadmin rights.

That's strange. When I bought my YubiKey a year ago from Amazon it costed like $100.

In T197160#11679885, @RoySmith wrote:

In T197160#4281158, @Bawolff wrote:

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

@Bawolff 's point is entirely valid, and was even more so when it was written 8 years ago. But...

In a previous job, the setup was that 2FA was via a Yubikey. We had those cute little things that plugged into a USB-A port and just had a nubbin sticking out. One lived in a port on my laptop all the time so re-authing was as simple as reaching out with a fingertip and tapping. Now we're in 2026 and this sort of tech has become ubiquitous even on consumer-level hardware. Right now, I'm working on my personal machine with Touch-ID, so basically the same setup.

Yes - while the details still need to be worked out, re-authentication of some form, for some sensitive actions, is in our plans. I think "re-authentication" also projects a kind of bluntness that doesn't have to reflect how it's implemented (doesn't need to be the full login flow), or the security goal that it would have (doesn't need to care about every risk that logging in does).

In the last 8 years, there are now multiple distinct kinds of authenticators (not just portable hardware Yubikey-style keys) that all speak WebAuthn and can serve this goal. @RoySmith, you didn't use the term passkeys, but TouchID on your personal machine is a good example of one. People can also use all kinds of software-based authenticators, and can store passkeys in cloud-synced services like 1Password. Some of these newer things may be "less secure" than hardware-backed non-exportable keys for some purposes, but any WebAuthn-backed method, hardware or software, works just fine for some really important situations:

• Remote account takeover -- preventing an attacker from either logging in with stolen credentials, or fooling a user into logging into a phishing site. (Phishing sites can easily cut through non-WebAuthn-based methods, like TOTP on most authenticator apps, SMS, push notifications, etc..)

• Re-authentication: requiring a user to be present and to take physical action to allow something to take place. Many passkeys also verify it is the right user locally in some way (like with a fingerprint), while some hardware Yubikeys are just a button push -- but in either case, they create the foundation to make it impossible for a malicious user script to take a sensitive action on a user's behalf without the user's participation. It may take some further work to create a flow that can resist a user script also trying to mislead the user about why they're being asked to push a button, but with effort this seems possible.

The usability vision for this is basically what @RoySmith lays out - that we have a system where for most people, most of the time, both their original login, and any re-auth checks, are very simple and don't require owning fancy hardware or having to dig anything out of your pocket, whether you are on a laptop or a phone or something else. The availability of passkeys, despite the various rough edges still present in the passkey ecosystem, gives us options that are secure and more usable than what was feasible 8 years ago.

I have two PCs and one laptop from which I contribute. I also use two phones. Passkeys are not that great for such a situation, to say the least. Password managers solve most problems that passkeys solve (2FA solves the rest of them) and support more setups.

It is worth noting that having to enter a password for sensitive operations should be enough to confirm those operations, as on the login page user scripts and gadgets don't work. The last breach would not have happened if just the password had been required. The risks didn't really change, so there is no need to require both a password and a second factor, or require a passkey, which is kind of both at once as well.

Perhaps you might want to require more from Staff accounts, as the last self-breach was from a Staff account. In any case, those kinds of accounts should not be used casually; perhaps only in a separate browser (so that part would be more about procedures and training for the staff, not that much about software). Most users cannot make vast edits on many projects, hence the risks are also vastly different. And security should be based on risk assessment.

In T197160#11689990, @Nux wrote:

Password managers solve most problems that passkeys solve (2FA solves the rest of them) and support more setups.

Not very well, passkeys are domain-bound, password managers aren't (or at least aren't in a way we could trust) so they are vulnerable to phishing (which can be easily incorporated in an XSS attack).

Modern password managers do support passkeys, though (e.g. if you use Chrome, it will just store your passkeys in the Google cloud and make them accessible on all devices).

there is no need to require both a password and a second factor, or require a passkey, which is kind of both at once as well.

I don't think it's smart to ask for the password and omit the 2FA when we could ask for the 2FA and omit the password, and that's significantly more secure. But yeah, there's no point in asking for both. It's an implementation limitation (see the links in the task description), we are basically just sending you through login again. I hope we can improve that soon.

In any case, [Staff] accounts should not be used casually; perhaps only in a separate browser

I think that would require a policy change for use of staff accounts (as in, accounts of WMF staff, not necessarily accounts in the staff usergroup). In any case, it isn't really on topic for this task - there is plenty of risk in non-staff accounts to justify requiring a security check for JS edits.

Not very well, passkeys are domain-bound, password managers aren't (or at least aren't in a way we could trust) so they are vulnerable to phishing (which can be easily incorporated in an XSS attack).

No password manager I know of will do autocomplete on wikipędia.org, so that would be quite enough for most phishing use cases. Also the recent "attack" was not about phishing. Requiring just a password, I think, would be enough and would block most mishaps like the recent incident or more real threats (such as when malicious code would be obfuscated; I've seen the script; the mishap was avoidable with just human procedures in place). The risks didn't change that much, so please don't escalate security too much. Security is almost always added at the expense of UX.

I have two PCs and one laptop from which I contribute. I also use two phones. Passkeys are not that great for such a situation, to say the least. Password managers solve most problems that passkeys solve (2FA solves the rest of them) and support more setups.

Those are complementary. You can either add a local passkey from each device to your account, or one cloud-based passkey (like one stored in a password manager like 1Password or Bitwarden) that you can sync across those things, or any combination of that.

In any case, those kinds of accounts should not be used casually; perhaps only in a separate browser (so that part would be more about procedures and training for the staff, not that much about software).

Indeed, I'll go further than @Tgr, actually, and say that I think it's very likely we would start with staff accounts (at least ones that have powerful rights), so we can work out usability issues there first. But so it's clear, we're not responding just to the script at issue last week and we're talking about work that we've been building toward for many months now, and would be important for many kinds of attacks and many users with powerful rights.

In T197160#11690429, @Nux wrote:

No password manager I know of will do autocomplete on wikipędia.org

But they will autocomplete on wikipedia.org. If an attacker pulls out a successful XSS attack, they can just present a fake login form right there, no need to complicate things with sending the victim to another domain.

The risks didn't change that much, so please don't escalate security too much.

IMO the risks didn't really change, but the incident highlighted how much we have underinvested in security for a long time. This is something that should have happened a decade ago. Sometimes what blocks action is the lack of shared understanding, and hopefully that did change.

In T197160#11691938, @Tgr wrote:

In T197160#11690429, @Nux wrote:

The risks didn't change that much, so please don't escalate security too much.

IMO the risks didn't really change, but the incident highlighted how much we have underinvested in security for a long time. This is something that should have happened a decade ago. Sometimes what blocks action is the lack of shared understanding, and hopefully that did change.

Yes, I do agree here. I've been saying this for years, so I agree that this might be the best thing that comes from the recent incident.

However, I still think in most situations a password should be enough. Typically, the second factor is used to establish trust between the service (here Wikipedia) and the user's browser. Hence you don't need to use it often, and in many cases you only ask for it once a month or similar, even between logins (this is something e.g. LastPass does). So when you ask for a password you still get something the XSS attacker doesn't know as he doesn't have access for the login screen. Crucially for UX, users can enter the password without getting their phone from a pocket, from behind the couch cushions, or wherever the phone was left. So passwords are less friction, but still block most ~XSS attacks.

If you want to block phishing attacks, that is where storing IPs would help. Wikipedia already stores my recent IPs so it knows my rough location. You can simply require the 2nd factor when connecting from an unknown location (which can be as simple as an IPv4 /24 or /16, or an IPv6 /32 check). This would block most phishing attacks without extra friction for users.

I don't know if this has been raised before, and it seems like it haven't - Any changes we make to the editing process may either be circumvented by using the API (mw.Api), or may block bots from doing their chores. Where will be our sweet spot?

However, I still think in most situations a password should be enough. Typically, the second factor is used to establish trust between the service (here Wikipedia) and the user's browser.

That's not how we think about the security model for two-factor authentication - it's there, and required for users with various kinds of powerful rights, because of the plausibility that someone's username and password becomes known by an attacker. Last year's account compromise incident was a reminder of how widespread stolen credentials are (whether from other breached services where passwords were reused, or compromised laptops someone logs in from, or other).

That's a general security model for most websites, but an additional risk that is more specific (unique?) to Wikipedia is our extensive use of gadgets and user scripts, which are very heavily used by users with powerful rights to do their work. And when the user script is compromised somehow, they are a vector to run code inside of someone else's secure session. We want re-authentication to be resilient to the same kind of plausible risk that an attacker may have a long-lived user secret (the user's password).

If you want to block phishing attacks, that is where storing IPs would help. Wikipedia already stores my recent IPs so it knows my rough location. You can simply require the 2nd factor when connecting from an unknown location (which can be as simple as an IPv4 /24 or /16, or an IPv6 /32 check). This would block most phishing attacks without extra friction for users.

We do take roughly this approach to when we challenge non-2FA users to paste in a code from an email we sent them. Filtering down that extra friction to only these kinds of situations helps a lot, but it nonetheless triggers way more than you might expect, to the point that we have also been building new features and interventions to try to ameliorate this problem (like making Special:AccountRecovery instead of having people email back and forth with ca@ for recovery).

Though this might sound like a semantic difference, we're more likely to increase the level of protection when coming from an unknown device/location than we are to lower the level of protection when coming from a known device/location.

In T197160#11697639, @EMill-WMF wrote:

However, I still think in most situations a password should be enough. Typically, the second factor is used to establish trust between the service (here Wikipedia) and the user's browser.

That's not how we think about the security model for two-factor authentication - it's there, and required for users with various kinds of powerful rights, because of the plausibility that someone's username and password becomes known by an attacker. Last year's account compromise incident was a reminder of how widespread stolen credentials are (whether from other breached services where passwords were reused, or compromised laptops someone logs in from, or other).

Yes, password can be stolen, and that is why you establish trust to the the user's browser, not only to his password. You don't need to re-confirm trust on each page view or even on each login. The trust token can be saved in a long term secure cookie (not readable from scripts).

That's a general security model for most websites, but an additional risk that is more specific (unique?) to Wikipedia is our extensive use of gadgets and user scripts, which are very heavily used by users with powerful rights to do their work. And when the user script is compromised somehow, they are a vector to run code inside of someone else's secure session. We want re-authentication to be resilient to the same kind of plausible risk that an attacker may have a long-lived user secret (the user's password).

Yes, that's why you have to re-confirm some action in the browser on a login page and that login page is not loading gadgets nor user scripts. So password is enough.

In T197160#11697581, @1F616EMO wrote:

I don't know if this has been raised before, and it seems like it haven't - Any changes we make to the editing process may either be circumvented by using the API (mw.Api), or may block bots from doing their chores. Where will be our sweet spot?

Krinkle wrote about this here: T419152#11683994 (it sounded like BotPasswords would be excluded from extra hoops to jump through, as bots are not really subject to XSS).

In T197160#11696361, @Nux wrote:

However, I still think in most situations a password should be enough.

It certainly doesn't make sense to ask for both the password and the 2FA (that's a technical limitation of the current implementation). But once we can skip one of those checks, it would be silly to skip the much more secure one, when (with WebAuthn) they take a comparable amount of effort.

If you want to block phishing attacks, that is where storing IPs would help.

I hope we can do something like that to protect against session theft (it's one of the ideas for T210909: Introduce secure mode to MediaWiki), but it's hard to do it in a non-disruptive way, mobile devices can jump between networks a lot these days, without the owner even noticing. In any case, if we can just use reauthentication (which already exists) to block phishing, why depend on another complicated and hard-to-get-right thing instead?

In T197160#11699890, @Tgr wrote:

In T197160#11696361, @Nux wrote:

However, I still think in most situations a password should be enough.

It certainly doesn't make sense to ask for both the password and the 2FA (that's a technical limitation of the current implementation). But once we can skip one of those checks, it would be silly to skip the much more secure one, when (with WebAuthn) they take a comparable amount of effort.

I agree with the first part, but I don't agree with the conclusion. Your wording is unfortunate ;), but I don't mind and I won't use it against you. Security is always about layers. Since the incident, more layers have been added. That is fine as long as it doesn't cause too much friction for users actually adding content to Wikimedia websites and for users who help others add and manage that content (let's call them local devs).

Yes, that will be hard. I know, I'm a tech lead, so I plan and partially implement these kinds of things. I always say a dev should work hard once so thousands (or millions) of users don't have to.

In T197160#11698961, @Nux wrote:

In T197160#11697639, @EMill-WMF wrote:

However, I still think in most situations a password should be enough. Typically, the second factor is used to establish trust between the service (here Wikipedia) and the user's browser.

That's not how we think about the security model for two-factor authentication - it's there, and required for users with various kinds of powerful rights, because of the plausibility that someone's username and password becomes known by an attacker. Last year's account compromise incident was a reminder of how widespread stolen credentials are (whether from other breached services where passwords were reused, or compromised laptops someone logs in from, or other).

Yes, password can be stolen, and that is why you establish trust to the the user's browser, not only to his password. You don't need to re-confirm trust on each page view or even on each login. The trust token can be saved in a long term secure cookie (not readable from scripts).

Right, two-factor authentication (the full flow) is about creating a session cookie that was securely established. But the password factor is the less durable one when it comes to remote attacks. Some sites are allowing passwordless login for accounts with "two-factor authentication enabled" with passkeys that don't require user verification (which is basically a single phishing-resistant non-password factor). That's not a decision we've made, but the point is that the growth of passkeys and passwordless login is because password-based security is fundamentally unstable.

So when we refine our re-authentication implementation, it's just really unlikely that we would have that re-auth flow rely on just a password. The point of re-authentication in that moment is to have the highest confidence we can that the user who originally created this account and logged in is still the user making the decision to take a sensitive action. Hardware security keys and passkeys are a stronger guarantee of that goal.

That's a general security model for most websites, but an additional risk that is more specific (unique?) to Wikipedia is our extensive use of gadgets and user scripts, which are very heavily used by users with powerful rights to do their work. And when the user script is compromised somehow, they are a vector to run code inside of someone else's secure session. We want re-authentication to be resilient to the same kind of plausible risk that an attacker may have a long-lived user secret (the user's password).

Yes, that's why you have to re-confirm some action in the browser on a login page and that login page is not loading gadgets nor user scripts. So password is enough.

Fair point, you are right that some sort of intermediary interface that cannot be changed by compromised user scripts is likely a necessary part of how this will work. Even here though, we want whatever intermediary interface and flow we make to be irreproducible by a malicious script or phishing site, and for whatever factor people provide into it to be something that can't be taken and reused.

It is just fundamentally stronger. Relying on fundamentally stronger authentication factors also reduces the severity of other security bugs, especially ones we haven't discovered yet. Vulnerabilities that let someone bypass limitations on where attacker-controlled JS can run could still be inhibited by server-side enforcement of validating a WebAuthn-based cryptographic challenge that both proves user presence and cannot be successfully modified or reused by JavaScript running in the user's session.

I always say a dev should work hard once so thousands (or millions) of users don't have to.

That is well said. :) That is our mentality here as well, which is why we've put the energy we have into usability improvements alongside security improvements over the course of the past year. This recent change to add re-auth is unfortunately an example of us having to do the security work before the usability work, but we try to make that the exception to the rule.