Help talk:Two-factor authentication

SpBot archives all sections tagged with {{Section resolved|1=~~~~}} and sections whose most recent comment is older than 15 days. For the archive overview, see Help talk:Two-factor authentication/Archives.

Please do not lock us out

I have a following problem with the hard 2FA requirement: if 2FA does not work for some reason:

• broken/lost/misplaced phone
• broken WebAuthn key (happened to me, that is why I am writing this)

the person affected will not be able to log in to their account for even for a simple things, such as editing or community participation.

I think this is a very important thing - being away on a hackathon and having 2FA broken is really a big issue.

I read in the release notes that we finally can have recovery codes independent of the 2FA method chosen (at least they should work for WebAuthn now). This is very good news but I am not sure I want to travel with my recovery codes printed to Wikimania for example.

What if we will have to remove the last 2FA method from the account with the help of ca@ (because the hardware is dead) - will I also lose the extended rights?

Most people can probably survive such a disaster for some days without advanced rights, but having account access blocked can be very frustrating as it was to me.

If the user has no other device for the second factor, do we really think that "2FA" done in software on the same computer (as suggested in another thread here) is the security we want?

While on mobile, using 2FA can be hard or impossible or insecure - my security key didn't work with the mobile phone at all (some NFC issue probably). The help page says the mobile apps do not support security keys. Having 2FA application on the same phone we use to enter the password is ... questionable.

Why change this now? Do we have some new data that mandate this and keeping the current setup (extended rights temporarily disabled) is no longer good? Is there a more long term plan about how this thing should develop? For example, if we realize that the hijacking of a logged in session becomes a prevalent problem, you might need to change the set up again and introduce additional restrictions. You might want to introduce a periodic re-authentication for example.

Are the alternatives that were considered?

• What is wrong with status quo?
• can we think of other solutions, such as "sudo mode" - enabling extra flags on demand with 2FA?
• some other solutions?

Otherwise we might end up in a sad corporate-style reality (I know this first hand, which is another reason why I write this) where I need to pull out my authenticator multiple times a day to continue working.

 « Saper // talk »  20:45, 23 February 2026 (UTC)

Hi @Saper and sorry for late response.

Until now, 2FA couldn't have been fully enforced for Wikimedia accounts, because the OATHAuth extension supported only a single authentication method at a time. This meant that there were numerous legitimate reasons for 2FA-required users to turn off their 2FA (eg., when switching from one method to another). Recently, Product Safety and Integrity team updated the extension, so that multiple authentication methods are now supported. Now, it's possible to have a few YubiKeys, authentication apps and/or passkeys at once at your account. This makes it much less likely to lose all authentication methods.

What also changes it the recovery process. Trust & Safety used to disable user's 2FA, so that they would log in with just password. Now, T&S will generate additional recovery codes, instead. This enables user to log in to their account again and adjust 2FA as they wish (add another authentication app or whatever else they wish). In this model, 2FA will never be disabled during recovery.

And regarding the "second factor-same device" thing. What we'd like to prevent primarily are attacks like credential stuffing (similar to what we saw during spring 2025). Even if you log into Wikimedia on your phone, using authentication app there, an attacker who doesn't have access to your phone won't be able to log in.

Status quo is for sure safer than no 2FA enforcement at all. However, there's still a significant vulnerability. If an attacker obtained a password to an account with extended rights, they could log in, set up 2FA on that account and make use of the sensitive permissions. The current 2FA enforcement wouldn't prevent them from doing any harm. We perceive this as a significant weakness in the system. In fact, 14% of users who – by policy are required to have 2FA – don't have it.

Introducing a "sudo mode" is something that is considered for future (without exact specifications yet). However, if we wanted to mitigate the issue like it's now (attacker logs in — configures 2FA — has full access), we probably would need to mandate having 2FA on an account. And the "sudo mode" would be a mitigation primarily against potential malicious user scripts, which could try to perform mass sensitive operations on behalf of another user.

Regards, MSzwarc-WMF (talk) 19:28, 2 March 2026 (UTC)