Requests for comment/Expand two-factor verification as an option for all users on all wikis

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]


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"

Background and summary

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.

Thank you! --Rezonansowy (talk) 17:04, 10 April 2017 (UTC)[reply]

UPDATE: I would like to address some oppose votes on this proposal.

  1. 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.
  2. 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.
  3. The next step is to redesign (where needed) the 2FA mechanism and implement it as a beta feature first.

--Rezonansowy (talk) 05:29, 28 December 2017 (UTC)[reply]

Update 2: I added where needed to the redesign step to be more specific. --Rezonansowy (talk) 08:08, 28 December 2017 (UTC)[reply]

Votes and comments

Support

Oppose 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]
Overview of preferences section to enable two-factor authentication.
@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]
Hmm sorry for my misunderstood. As this is just allowing publicly opt-in/out selections and not another MediaViewer case, I change to
Support Support now. --Liuxinyu970226 (talk) 13:29, 23 May 2017 (UTC)[reply]
Strong support 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]
  • 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]
  • Support 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]
  • Support 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]
  • Oppose Oppose I don't see the word "optional" here. Yann (talk) 15:30, 29 May 2017 (UTC)[reply]
    @Yann: It is optional, please see my comment to Liuxinyu970226 and updated RfC summary. --Rezonansowy (talk) 08:46, 30 May 2017 (UTC)[reply]
    That looks like an oversight, the requester is asking that all users gain the ability to enroll. — xaosflux Talk 15:43, 29 May 2017 (UTC)[reply]
    Support Support, as long as it is optional. Yann (talk) 15:35, 30 May 2017 (UTC)[reply]
  • Support 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]
  • Cautious Support 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 (talkcontribs) 19:04, 29 May 2017 (UTC)[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]
  • Support 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. -- (talk) 09:04, 30 May 2017 (UTC)[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. — xaosflux Talk 10:52, 30 May 2017 (UTC)[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. (talk) 15:17, 10 June 2017 (UTC)[reply]

Oppose

  • Oppose 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]
    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]
    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]
  • Oppose Oppose, I agree with Ajraddatz. Matiia (talk) 02:47, 20 June 2017 (UTC)[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]
    @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]
    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]
    @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]
  • Oppose 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]
  • @Xaosflux, Ajraddatz, Matiia, and Parent5446: Please see my updated background of this RfC. I addressed most of your doubts there. --Rezonansowy (talk) 05:33, 28 December 2017 (UTC)[reply]

Comments

  • Comment 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]
  • Comment 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]