Product Safety and Integrity/Account Security
|
Account Security
Technically enforcing that all sensitive user rights are secured by 2FA
|
As the Product Safety and Integrity team, we want to strengthen the security of user accounts on the wikis. We are particularly focused on users with sensitive permissions. Compared to other internet platforms, an exceptionally high number of users are able to take security- or privacy-sensitive actions: stewards, checkusers, oversighters, interface administrators, and bureaucrats, to name a few groups. While these are generally trusted and competent members of the community, anyone can be phished or have their passwords stolen. If an account with such rights is taken over, it could be misused to hurt other users.
The end goal of this initiative is to technically enforce that all privileges that enable users to take security- or privacy-sensitive actions can only be performed by accounts that have enabled two-factor authentication (2FA). In 2025, we have already expanded 2FA enforcement to interface administrators, checkusers, and oversighters, and we will be expanding this further in 2026.
There are three main areas of technical development that will allow us to meet this goal:
- Improving the quality of our two-factor authentication system, by letting people register as many "factors" as they want, and by adding full support for both security keys and passkeys.
- Making two-factor authentication more widely available to the general user base, not just users with extended rights.
- Define and enforce policies that require 2FA for sensitive actions in the software, so that users whose accounts don't have 2FA can't take sensitive actions and can't be added to sensitive groups.
Timeline
[edit]- – We began technically enforcing 2FA for interface administrators, following a bulk account compromise.
- – We began technically enforcing 2FA for checkuser and oversighters.
- – We began gradually increasing the number of users who can opt-in to 2FA, while closely monitoring both uptake and our support desk load. We expect these gradual increases to continue through 2026.
- – We deployed the first wave of 2FA changes, including support for multiple authenticators and security keys, and general improvements to the user experience.
- – We expect to deploy a second wave of 2FA changes, focused on adding support for passkeys, and further improvements to the user experience.
- Early 2026 – We expect to have implemented a more consistent and reliable mechanism for enforcing 2FA for local and global user groups in MediaWiki.
- Throughout early/mid 2026 – We expect to expand 2FA enforcement for additional privileged user groups, in defined stages and with clear advance notice.
Making two-factor authentication easier to use
[edit]New Special:AccountSecurity page
[edit]We have redesigned Special:AccountSecurity, the 2FA management page, and made it the central point for everything related to account security. From this page, users can change their password, add or remove 2FA methods, and download their recovery codes. We will continue to improve this page and add features to it. We are targeting the end of 2025 for most major improvements to this page.
What authentication methods are supported
[edit]Historically, we have supported only one-time codes through a single authenticator app (like Google Authenticator) for two-factor authentication, with some limited experimental support for security keys (like YubiKeys).
After our recent improvements, users can now use any combination of multiple authenticator apps and multiple security keys.
We are next planning to add support for passkeys. This will allow users to store a passkey on their device or in their password manager, and then use that during login. Passkeys will generally be both the simplest and most secure way to log in to a user account, and we will encourage users to register as many passkeys as possible.
While some passkeys can be synced across multiple devices, not all devices support this and not all users will want this. So for the time being, we will be supporting passkeys conservatively, and treating them as always stored only in the device with which the user is registering the passkey.
To reduce the risk of users locking themselves out as they change devices, we will not support having a passkey as the only registered 2FA method. Users must first set up another method (an authenticator app or a security key) before they can register a passkey.
Making 2FA available to all logged-in users
[edit]Only users with certain kinds of extended rights, or those who have been specifically added to a particular group, can consistently see an option in their settings to manage two-factor devices. We are now gradually testing allowing more users to enable 2FA, while closely monitoring the enablement rate, to maintain confidence that any increase to the rate of recovery requests can be handled by our support desk.
Technical enforcement
[edit][To be filled out later - we are just starting this work]
FAQ
[edit]What roles are you going to enforce 2FA on? Will this include local admins on every wiki?
[edit]We have not finalized the set of roles for which we expect to enforce 2FA. We have been consulting with stewards and other users with extended rights, and we will remain sensitive to the impact on the user experience of our volunteers.
In our announcement of enforcing 2FA for checkusers and oversighters, we specifically mentioned bureaucrats as a role that we believe likely needs 2FA enforcement, given its ability to grant and revoke rights to other users. We also acknowledged the need to improve our 2FA system before enforcing it on additional roles, which is what we’re currently focused on doing before we make decisions on additional roles.
Why are you requiring me to enter a code from my email to log in? Can I opt out of this?
[edit]Starting in 2025, following the compromise of ~36,000 user accounts, we introduced an email confirmation step when we need additional confidence in a user login. While the conditions for when this happens may change over time, this typically occurs when logging in from unknown devices and/or network locations.
For most users, confirming a code from your email should be very infrequent. Users who clear their cookies and rotate network addresses will experience it more frequently.
If this is causing you issues, here are some options to make it easier:
- If you frequently clear your cookies, allow list the
loginnotify_prevloginscookie for auth.wikimedia.org. This cookie is not your session cookie and is much less sensitive. Leaving it present helps the platform know that you’ve used this device to successfully login before. - If you can, enable two-factor authentication (2FA) – this will disable email confirmation for your account. As of 2025, two-factor authentication is now much easier to use, and will continue to get easier.
- If you do not yet see the option in your settings to enable 2FA, and you are experiencing frequent email confirmation checks, you can request the two-factor tester right from a steward or (if there are bureaucrats on your wiki) a local bureaucrat. You can then opt in to 2FA for your account.
Users cannot opt out of this security protection. It is a necessary baseline for the security of Wikipedia in the current day.
Every human, no matter how experienced or technically capable, can have their passwords stolen, and the risk of user account takeover is not just borne by individual users. The integrity and reputation of Wikipedia as an encyclopedia written by and for human beings depends on keeping a tolerably high bar for authorized use of its user accounts.
