The following request for comments is closed. It is clear from the discussion that a significant number of participants want the two-factor identification to be expanded to all users as an opt-in option. However a number of significant technical concerns were raised against doing this now as this feature really is not ready for a wider use. So, I am closing this discussion as no consensus although this should not prevent developers from improving the two-factor identification feature and rolling it out to all users when they think it is ready. Ruslik (talk) 12:15, 31 December 2017 (UTC)Reply[reply]
This RfC was previously known under the following names: "Enable two-factor verification for all users" and "Enable two-factor verification as an option for all users"
I don't get the idea why only the limited amount of users are privileged to use Two-step verification on Wikimedia projects. This should not be a privilege but rather an extra security option for all users, as this is offered on other services like (Google, Microsoft, etc.).
For now the Special:Two-factor authentication page reports that this function is only limited to users in one of the groups: Administrators, Bureaucrats, Oversighters, Central notice administrators, Global renamers, WMF Office IT, WMF Support and Safety.
I think the Enable two-factor authentication (oathauth-enable) right should be available as an opt-in for all accounts from the Users group as this could enhance the security and clearly there is no reason to limit this function at all.
UPDATE: I would like to address some oppose votes on this proposal.
Enabling 2FA for all users means that we're making this function available to all users. It's optional and the deal is to allow everyone to enable this fiction in the their preferences.
This proposal is about the idea not the implementation. If they're are any technical obstacles which prevents the proper work of this mechanism, they'll be addressed. This RfC is to show the community support for the idea of Two factor authentication. This can have any desired form: scratch codes, SMS codes, OpenID login, social media integration, TouchID (fingerprint scan), FaceID (face scan), any other bio-metric scan, security questions, tokens, online banking login, government auth integration, etc. The discussion on it remains open for now.
The next step is to redesign (where needed) the 2FA mechanism and implement it as a beta feature first.
Update 2: I added where needed to the redesign step to be more specific. --Rezonansowy (talk) 08:08, 28 December 2017 (UTC)Reply[reply]
Votes and comments
Oppose Are you absolutely guaranteeing that all of the Wikimedians are having mobile phones or tablets? --Liuxinyu970226 (talk) 12:18, 12 April 2017 (UTC) cancelled at 11:20, 13 May 2017 (UTC)Reply[reply]
@Liuxinyu970226: This feature is an option not a mandatory way for login, so if you don't have a smartphone then just use the classic way for log in. Please see mw:Help:Two-factor authentication and you'll see that the user can enable or disable the two factor authentication in his preferences (see also image). --Rezonansowy (talk) 10:56, 16 April 2017 (UTC)Reply[reply]
Hmm sorry for my misunderstood. As this is just allowing publicly opt-in/out selections and not another MediaViewer case, I change to Support now. --Liuxinyu970226 (talk) 13:29, 23 May 2017 (UTC)Reply[reply]
Strong support I always thought that it was odd that only admins get this privilege. I am a stickler when it comes to 2FA and have always wanted this ability since its initial roll-out. TJH2018talk 15:53, 9 May 2017 (UTC)Reply[reply]
IIRC, wasn't the feature enabled only for admins and above because it wasn't entirely finished, and was pushed out as a quick security measure? Have the missing features/development been added? Samwalton9 (talk) 13:38, 29 May 2017 (UTC)Reply[reply]
That's different, but your confusion is understandable. OAuth and OathAuth are two different things, the latter being used for 2FA. – Ajraddatz (talk) 00:56, 17 June 2017 (UTC)Reply[reply]
Support as a optional feature available to all users, as long as it has been vetted and all issues worked out. --Masem (talk) 13:44, 29 May 2017 (UTC)Reply[reply]
Support as an optional feature. If there are problems then users should be advised before enabling, but there's not apparently any problem that makes it unsafe to use since it's already available to some user groups. Ivanvector (talk) 14:00, 29 May 2017 (UTC)Reply[reply]
Oppose I don't see the word "optional" here. Yann (talk) 15:30, 29 May 2017 (UTC)Reply[reply]
@Yann: It is optional, please see my comment to Liuxinyu970226 and updated RfC summary. --Rezonansowy (talk) 08:46, 30 May 2017 (UTC)Reply[reply]
That looks like an oversight, the requester is asking that all users gain the ability to enroll. — xaosfluxTalk 15:43, 29 May 2017 (UTC)Reply[reply]
Support as long as it's optional. I would be opposed to require this feature for anyone. עוד מישהוOd Mishehu 17:23, 29 May 2017 (UTC)Reply[reply]
Cautious Support, when the remaining small problems with 2FA become more prominent, they'll likely get fixed sooner too. Waiting for unscheduled development seems like a good guarantee to wait a very long time. Maybe first enable on meta only indeed. —TheDJ (talk • contribs) 19:04, 29 May 2017 (UTC)Reply[reply]
I think "as an option" helps in describing this discussion, but you might consider saying "expanding two-factor verification access" or similar. "Enabling... for all users" is technically accurate, but very easy to mis-read and consequently misunderstand. The current situation is that two-factor authentication is already enabled and available on Wikimedia wikis [for certain users], but you want to expand access to the functionality to all users. --MZMcBride (talk) 20:47, 29 May 2017 (UTC)Reply[reply]
Support on the understanding that how users can reset their account needs to be made easier. To be clear, if someone loses their spare 2FA reset codes, there is nothing stopping us having a system where a steward can use their judgement to reset the account, though in most cases I'd imaging that a logged-in user should be able to solve this for themselves, per phab:T150601. That particular manual scenario for account reset represents no real risk to security, the only apparent reason to resist offering that process is because it takes effort from someone with access; so a better answer is to have a better volunteer run 2FA reset/help process with some guidelines as to what is required for someone to reset their account. If necessary we could require all new 2FA applicants to have an SHA512 commitment to identity using an encoded phrase that includes a current mobile number or confidential email address, enabling a confirmation message to be exchanged to support a reset, if that were thought necessary by a steward.
By the way, I'm writing using a borrowed laptop on borrowed wifi. Not an uncommon scenario for many Wikimedians. So the fact that I had to log in using my password plus 2FA using my mobile phone app (Authy), gives me confidence that it's highly unlikely that my account will ever be compromized, even if the laptop is passed on to others with the history being wiped clean, or if I am logging in using free public wifi when travelling. --Fæ (talk) 09:04, 30 May 2017 (UTC)Reply[reply]
Any requirement that a hash of a specific secret is unprovable without revealing the secret. A digital signature could be used with public key cryptography, but that is way above the technical expectations for most editors. — xaosfluxTalk 10:52, 30 May 2017 (UTC)Reply[reply]
Users can be advised that these should be disposable, and that they could add as many as they like, so long as they keep a record of their starting phrases. It's hardly an obstacle. Fæ (talk) 15:17, 10 June 2017 (UTC)Reply[reply]
Support Optional 2FA should be on all popular websites EoRdE6 (talk) 21:47, 31 May 2017 (UTC)Reply[reply]
Support Even when optional, I can enable it whenever I can. I've done this in other websites. I should do the same for all wiki projects. --George Ho (talk) 03:14, 2 June 2017 (UTC)Reply[reply]
Strong support Better account security is important, especially for users with significant editing histories or special userrights. Train2104 (talk) 22:26, 5 June 2017 (UTC)Reply[reply]
Support. This gives an option for participant to improve the security of their accounts exponentially without an obvious downside. I cannot believe this is not open on day 1. Bluedeck 06:17, 6 June 2017 (UTC)Reply[reply]
Support, why not? This may attract our potential users who are concerning about security issues. Enabling it only on meta is a good idea in consideration of technical reasons.(Edited) --WhitePhosphorus (talk) 03:12, 7 June 2017 (UTC)Reply[reply]
Support, of course. More people testing means issues can be found out and fixed more quickly, therefore helping the feature to stabilize faster. -- Patrickov (talk) 06:24, 14 June 2017 (UTC)Reply[reply]
Support, if users are forced to read about the risks and the general procedure before enabling it. --Zenith4237 (talk) 19:06, 17 June 2017 (UTC)Reply[reply]
Strong support This is a thing on many other sites, and even though "normal" users don't have access to the same sensitive tools as sysops and etc. it would still be a good idea to make optional 2FA possible for everyone. Reception123 (talk) 09:08, 2 September 2017 (UTC)Reply[reply]
Very strong support I see no valid reason why all users should not benefit from this. Wikimedia has been exemplar when it comes to switch to HTTPS for everyone, but is late to the switch to 2FA for everyone. — Arkanosis✉ 15:12, 28 November 2017 (UTC)Reply[reply]
Support: (en-wiki) My account with RB and PRC can be used to do a lot of damage if my password is cracked (which isn't easy on my account, maybe 10 years?). But, for other users around and under my level, they might not have secure passwords and can be easially cracked. I have a Commited Identity that I can use to get back into my account in case I were to lose my 2FA. Cocohead781 (talk) 03:08, 6 December 2017 (UTC)Reply[reply]
Very strong support If server load is not a problem, I can not see why oppose to this. --Hentailolicon (talk) 14:51, 16 December 2017 (UTC)Reply[reply]
Oppose for now, pending some improvements to phab:T100375. This isn't being "held back" (and users that really really want it can get it turned on) but it is still a bit of a beta-feature and there is no way for normal project members to reset the 2FA status of someone if they break their account. — xaosfluxTalk 15:46, 29 May 2017 (UTC)Reply[reply]
Possibly as a compromise - enable it on meta: only; that way normal project editors that really want it would have to purposefully drop by here first? — xaosfluxTalk 15:47, 29 May 2017 (UTC)Reply[reply]
@Rezonansowy: I understand, this suggestion is to add it to the users on metawiki, but not WMF wide. It would eliminate the needs to stewards to rubber stamp testers, but enable users that want to go out of their way to come here and enable it. — xaosfluxTalk 16:26, 29 May 2017 (UTC)Reply[reply]
Enabling just on Meta sounds reasonable, though the scratch code issues would still continue with any expansion of the people with 2FA. – Ajraddatz (talk) 07:44, 14 June 2017 (UTC)Reply[reply]
Responding to the new scope: I'm in support of optional opt-in 2FA in general, once the technical and process issues are ready. — xaosfluxTalk 05:54, 28 December 2017 (UTC)Reply[reply]
Oppose because of the issues we've already had with people losing scratch codes. Until a better system is devised, or the 2FA can be removed without them with a few day waiting period, I don't think it should be further rolled out. People who understand the risks, and who don't hold super-special userrights can always request access to 2FA at SRGP. – Ajraddatz (talk) 07:38, 14 June 2017 (UTC)Reply[reply]
Ajraddatz: thank you for having pointed out the possibility for anyone to get access to 2FA :) I'm afraid, though, that close to nobody is aware of this (I wasn't), which makes it pretty much the same as if it wasn't possible. If anyone has an idea on how to advertise this without causing people who do not understand the risk to jump into the boat, that would be a significant improvement over the current situation IMHO. Thanks again :) — Arkanosis✉ 15:34, 28 November 2017 (UTC)Reply[reply]
Responding to the updated background, of course I support enabling 2FA for everyone once it is technically feasible. Such an action would not even require an RfC. – Ajraddatz (talk) 05:53, 28 December 2017 (UTC)Reply[reply]
You said This proposal is about the idea not the implementation. If they're are any technical obstacles which prevents the proper work of this mechanism, they'll be addressed. This RfC is to show the community support for the idea of Two factor authentication. I don't think anyone thinks that. Users think that if this RfC is successful, then everyone using an account may enable 2FA. Matiia (talk) 18:12, 28 December 2017 (UTC)Reply[reply]
@Matiia: Both statements are true. If this RfC is successful, then everyone using an account may enable 2FA – this is the final effect. Obviously if there are any security holes or design weaknesses, then they need to be fixed in order to deploy this functionality on Wikimedia projects. Every user vote of support here is to provide functionality and nobody cares about scratch codes. --Rezonansowy (talk) 20:52, 29 December 2017 (UTC)Reply[reply]
Yes, and I still oposse this until all issues are solved. It may take a few years, well, let's wait a few years and then enabling it for everyone. Nobody thinks this is just an idea. Once this RfC is closed, they expect us to create a ticket on phab and 2FA to be enabled for everyone. I'm not sure what you mean by Every user vote of support here is to provide functionality and nobody cares about scratch codes. Matiia (talk) 02:47, 30 December 2017 (UTC)Reply[reply]
@Matiia: I'm not sure what are you opposing to but I also expect to create a ticket on phab and enable 2FA for everyone. I mean that we simply want 2FA as soon as possible, but this doesn't have to be in current shape. --Rezonansowy (talk) 04:59, 31 December 2017 (UTC)Reply[reply]
Oppose My opinion is a bit dated, as I have not been involved with the project in a while due to other commitments, but the main reason 2FA was not rolled out universally is that it was not ready, both technically and policy-wise. With regards to technical features, if Phabricator is up-to-date, then there is still no way to generate new scratch tokens, and the special page does not obey $wgSecureLogin (among other smaller features, such as notifications for when scratch tokens are low and audit logging). These features are critical for 2FA to be secure and function properly, otherwise there will be a large uptick in users accidentally locked out of their accounts at best, and account compromises at worst. Probably more important is the policy side though. There is an important question of what to do for users who lock themselves out of their account, which happens quite often. Personally, I think the answer is "create a new account". 2FA is a serious security feature that should not be easily circumvented. There's some discussion of letting functionaries (or some other user group) be able to reset 2FA, but it seems the question is far from resolved. It would need to be decided exactly who would have the power, what the process would be, etc., not to mention technical features to support the process. In the end, it's no question that letting all users use 2FA is a goal, but considering the low value of most wiki accounts, I think doing so now would cause significantly more pain for sysadmins than would actually be gained in account security. Parent5446 (talk) 22:32, 27 December 2017 (UTC)Reply[reply]
Comment People may want to look at the open subtasks of T100375 Improve user experience of Two-Factor process when considering whether issues have been sufficiently worked out. I believe Samwalton9 recalls correctly that it was pushed out to admins in response to a series of attacks on admin accounts despite the user experience still being lacking. Anomie (talk) 14:20, 29 May 2017 (UTC)Reply[reply]
Comment. 2FA was enabled as an emergency measure and while I've got no problems with it myself, there are open tasks about not-enhacement features. I've also seen quite some requests of people who loose the 2FA keys and scratch codes and get locked out of their accounts, which requires sysadmin intervention, and it takes time to verify to avoid attemps of social engineering and fraud. Currently they can handle the low number of requests we receive, but I bet that if we were to enable this for everyone we can expect a sudden increase of such requests, which will likely be rejected on the spot if the account does not have any substantial edit history. I know that is not really a blocker, because users enabling 2FA should be responsible, but I fear enabling it for everyone right now. On the other hand, lots of other sites on the net allow recently registered contributors to use 2FA so it could work the same here I guess. I'd welcome comments from tech people to know if there are any serious blockers so I could have a more informed opinion. —MarcoAurelio 14:29, 29 May 2017 (UTC)Reply[reply]