The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section.
Closed as successful. John (talk) 19:16, 27 April 2022 (UTC)[reply]
While I said on IRC and on Phabricator security ticket #T9071 that I would've preferred a community discussion take place prior to RhinosF1 implementing this configuration change to Meta Wiki, given that Meta Wiki is both central project coordination wiki used for, among other things, control over pan Miraheze configuration changes affecting user rights, ManageWiki changes, and the like, and the potential for harmful JS code to be inserted, it is prudent and cautious to require users requestin the Meta bureaucrat sub-delegated discretionary interface administrator role rather than have to be reactionary.
* Have two-factor authentication enabled on their account
Additionally, for the sake of clarity, it is further clarified and codified that the eligibility requirements past the point of granting by a Meta bureaucrat continue while the holders continue to hold the permission.
This would be functionally implemented by adding editsitejs and editsitecss to the $wgOATHExclusiveRights MediaWiki PHP variable for metawiki
As such, a Meta bureaucrat may request a Steward to verify a holder's two-factor authentication status at any time, either by posting a request at stewards' noticeboard or via e-mail to stewardsmiraheze.org.
It's important to note that Wikimedia already requires this on their wikis, and we're not even proposing to require this globally, at least at this stage. Any such potential change, if considered, would follow a global community discussion, which Stewards would close. This discussion, however, will be closed by an ideally non-participating Meta bureaucrat.
As an aside, whenever any Meta interface administrator has requested the permission, they've often been surprised that two-factor authentication has not been a requirement, given the above.
Support 'editsitejs' is a powerful right which, if in the wrong hands, can cause serious damage and potential security issues. 2FA is very simple to set up and recommended either way, so I can see no good argument against this. Reception123(talk) (C) 20:04, 16 April 2022 (UTC)[reply]
Support per above, and as a common sense that should have been added in the last Meta RfC on the matter that Amanda Catherine had initiated. As well, I would like to point out that while Stewards, SRE, and Trust and Safety are not required by policy to have two-factor authenticated enabled on their accounts, the constituent members have all groups have supported that technical requirement as a very good security practice, and so that was implemented by SRE. In other words, a constituent member of either of those groups could be a member of those groups, but not functionally carry out any activities within those groups until they enabled two-factor authentication. Dmehus (talk) 20:10, 16 April 2022 (UTC)[reply]
Support This really should have been a requirement before, but this is a central coordination wiki for Miraheze, therefore having more users (automatically created) than other wikis. As such, if an account holding this right gets compromised, could allow for malicious code to be implemented on this wiki. There is no reason why this should not be added, especially since 2FA is easy to set up. -- Cheers, Bukkit ( Talk • All Contribs ) 20:25, 16 April 2022 (UTC)[reply]
Support while I did not support doing this without community established consensus, I do support the action. They are powerful rights that should have 2FA enabled to use.
Support Meta is a special wiki and a very sensitive one. This is the only wiki where you can remotely change user rights from, assign global rights and do many more sensitive things. As such, it would make sense to require that those who can edit the interface be subjected to extra precautions to prevent a potentially compromised account from affecting the farm globally. AgentIsaiTalk to me! 20:56, 16 April 2022 (UTC)[reply]
Support Given the sensitivity of Meta as a wiki, interface administrators here should follow the same security requirements as Stewards and such, which includes two-factor authentication. — Chrs (talk) 22:11, 16 April 2022 (UTC)[reply]
No, Stewards aren't required to have 2FA, this RfC wants to have just local interface-admins with 2FA, making this already absurd RFC even more absurd. Naleksuh (talk) 23:10, 16 April 2022 (UTC)[reply]
As I stated already above, Stewards, together with SRE and Trust and Safety, have, by convention, unanimously agreed to have two-factor authentication enabled. I assumed that when SRE implemented the more stringent password length requirements, they also made a technical change, with the support of Stewards, SRE, and Trust and Safety, that made this long-standing convention a technical reality. If that is not the case, I would have no objections to SRE also implementing that for any of the aforementioned groups upon the closing of this community discussion. Dmehus (talk) 23:36, 16 April 2022 (UTC)[reply]
Weak support per above stuff Anpang📨 05:09, 17 April 2022 (UTC)[reply]
Weak support While I do believe that the chances of an interface administrators' account being hacked or compromised are quite low it is still a possibility that can be easily avoided by installing two factor authentication. It does not seem to me to be imposing a large or unreasonable burden on interface administrators since as it has been mentioned in the oppose section as a response to the only oppose comment having a mobile phone is not a requirement for having a functional 2FA system. Rather than an obligation I would have preferred for interface administrators' to understand the risk of their account being compromised and what kind of damage can be done with their rights but given the comments made by an interface administrator below it seems to me that that is not the case. I therefore come to the conclusion that it must be made mandatory if interface administrators are not able or willing to take the initiative themselves to take appropriate steps to keep their accounts safer. The opposing arguments do not convince me because the mobile phone aspect has already been discounted and the opposer himself admits that even though he has a strong password "[t]wo-factor authentication is designed to handle a scenario in which someone steals this password" which identifies the need for it. --DeeM28 (talk) 11:20, 18 April 2022 (UTC)[reply]
This is not okay. First of all, there is very little if not zero conceivable benefit to this change. I already use a secure password which will take 500 quadrillion years to crack. Two-factor authentication is designed to handle a scenario in which someone steals this password but doesn't steal 2FA. 2FA on Discord is widely criticized for doing absolutely, and while it is less of he case on MediaWiki it's still absolutely problematic, and the security benefit is not only negligible, but not the responsibility of others. And more importantly, since I do not carry a smartphone, this change would essentially force me to resign as an interface admin. While interface admins are responsible for protecting their account and are free to enable it, it is absolutely unacceptable to try to be forcing other editors to enable it. User:Reception123, it is extremely concerning that you "can see no good argument" against forcing editors to enable a specific feature, much less one that requires carrying a smartphone and identifying yourself. This is unacceptable. Naleksuh (talk) 20:50, 16 April 2022 (UTC)[reply]
It does not require a smartphone at all. You develop bots so I'm sure you can find a simple programming function for TOTP functions. I'm sure at least one website has a function for storing 2FA tokens. ~ RhinosF1 - (chat)· acc· c - ( online) 20:54, 16 April 2022 (UTC)[reply]
As RhinosF1 said above, it does not require a smartphone. I don't use a smartphone either, and have the non-Google Authy app installed, for free, on two computers, allowing my two-factor authentication credentials to be synced on both devices, so that portion of your argument is moot/void. Dmehus (talk) 20:56, 16 April 2022 (UTC)[reply]
It's the responsibility of the user to keep their account secure. If there had been multiple occasions of interface administrators accounts being compromised, all of which could have been stopped by 2FA (so no phishing, no server-side breach, no device malware, etc), then maybe. But this RfC is a solution looking for a problem. And one that is also very disruptive. Naleksuh (talk) 21:17, 16 April 2022 (UTC)[reply]
It's not about seeking a solution for a problem; rather, it's about implementing a measure proactively as a preventative measure (just as Phabricator ticket #T9071 illustrates, or will illustrate, when/if it is made public), rather than having to potentially act reactively, which would be far more damaging and potentially catastrophic. Given the low barrier to the obtaining the interface-admin permission (i.e., it's a sub-delegated role granted by a Meta bureaucrat to users upon their request and apparent trustworthiness with a valid need) and as the views of the community have expressed thus far, Meta Wiki is a special wiki, this is quite prudent. Dmehus (talk) 21:25, 16 April 2022 (UTC)[reply]
If it's such a low barrier then there would be no reason to protect it so stringently. Even more reason to oppose this RfC. Naleksuh (talk) 21:27, 16 April 2022 (UTC)[reply]
Low barrier in the sense of that was the idea behind the original RfC, to allow users to request the permission without requiring a community election, as is the case of the sysop permission. The idea was to allow trusted users to assist Meta administrators and Stewards in fulfilling certain requests. That's not to say it's not a sensitive position; it is. It's just one that doesn't require a community election. Dmehus (talk) 21:31, 16 April 2022 (UTC)[reply]
This is to prevent any events happening with compromised accounts. Also, this change is not disruptive. I'm afraid that it's just needed to protect the site from any events in the future. -- Cheers, Justin Aves (talk • contribs • global • rights) 01:11, 17 April 2022 (UTC)[reply]
No, it is not "just needed". There are already security requirements in place, nor does 2FA stop all compromises from taking place. Naleksuh (talk) 02:00, 17 April 2022 (UTC)[reply]
Agreed. While I wouldn't necessarily want my health insurance company snooping on what I eat, I also wouldn't enable two-factor authentication on a smart fridge (nor would I buy a smart fridge). Dmehus (talk) 01:19, 17 April 2022 (UTC)[reply]
Update on this: my provider is killing my old 3G non-android phone, so it looks like I will need to overcome my fear of smartphones. However, I still oppose this RfC and you should too. Naleksuh (talk) 17:35, 25 April 2022 (UTC)[reply]
As a general point I would like to mention that if we are imposing 2FA for interface administrators I think there should be more clarity as to whether this is imposed for Stewards, SRE and Trust and Safety or whether this is simply done by agreement because the people in those groups are clearly responsible and know that they should secure the accounts. If there is no requirement and in theory someone in these groups could refuse to enable 2FA I believe there would be a bit of a bizarre situation created if only interface administrators are required to enable 2FA. I do acknowledge that on the other hand there is the argument that those three groups are already trusted enough to enable 2FA while interface administrators require less trust to be appointed. --DeeM28 (talk) 11:26, 18 April 2022 (UTC)[reply]
It would be enforced at the technical level. The rights would have no effect without 2FA. ~ RhinosF1 - (chat)· acc· c - ( online) 11:45, 18 April 2022 (UTC)[reply]
The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section