Wikipedia talk:Administrators' newsletter/2017/3

Edit filters

Do we really want to include the tidbit about edit filters? A very low percentage of administrators use edit filters directly, and even among those, most (all?) won't even notice the change. It doesn't require any action on their part. ~ Rob₁₃^Talk 03:12, 27 February 2017 (UTC)[reply]

Agreed, I've removed that bullet point — MusikAnimal ^talk 05:17, 1 March 2017 (UTC)[reply]

2FA

Those numbers are kind of shocking, considering the high profile compromised accounts that led to 2FA being rolled out for admins. It really is very simple to use, I don't get why so few admins are doing so. Beeblebrox (talk) 06:25, 1 March 2017 (UTC)[reply]

I certainly hope this number will rise. Additionally, I would like to see 2FA being mandatory for advanced permission holders in the very least. Mkdw ^talk 06:28, 1 March 2017 (UTC)[reply]

I choose not to use it because many tools I use have not rolled out meaningful 2FA support. Some of these include tools I use with admin tools. I could do a "workaround" by which I enable 2FA but also create a bot password with full rights, but at that point, I'm essentially as vulnerable as not using 2FA. Access to the account via bot password would be identical to access of any normal admin account. We need the full suite of tools that admins may use (Huggle, AWB, ForTheCommonGood, MTC!, and many more) to support 2FA before the administrator users of those programs would receive any benefit from 2FA. ~ Rob₁₃^Talk 06:43, 1 March 2017 (UTC)[reply]

The same rationale applies to myself. Whenever i log in on Wikipedia i tend to login with Huggle on a bot account which has blocking and deletion rights so if someone were to compromise my account directly 2FA wouldn't counter that (On the bot account that is). Beyond that multifactor authentication is quite often just a mitigation for bad account security practices such as password re-usage across multiple sites and the lack of occasional password changes. If everyone kept basic password and system security practices in mind that would already counter the majority of the account breaches. Excirial ^{(Contact me,Contribs)} 09:09, 1 March 2017 (UTC)[reply]

To my knowledge, it would counter 100% of the ones that have already occurred. I believe each was determined to have a compromised password from previous data breaches on another site. ~ Rob₁₃^Talk 10:53, 1 March 2017 (UTC)[reply]

The most recent compromise of admin accounts was due to password reuse (something that goes against basic password security anyway) - however, 2FA would have prevented the login and thus the attacks we saw. I would strongly advise anyone with access to checkuser/oversight perms to enable it at the very least. Forcing it on all administrators here would be "wonderful", but clearly it would cause more problems than it would solve - I would like to be able to re-run that query in say six months and see a significant increase though.. -- Samtar ^{talk · contribs} 15:52, 1 March 2017 (UTC)[reply]

I'm not shocked when you consider that using 2FA means you can be locked out of your account, without recourse to something like a password reset, if you lose your scratch codes. As has been said, recent breaches have been due to password reuse. I have a strong password which I do not use anywhere else, so I'm not convinced it's worth it for me. Yes, I could use a committed identity, but that's just another piece of data that must be precisely and safely stored—same principle. BethNaught (talk) 15:08, 2 March 2017 (UTC)[reply]

While we're on the subject, another thing that woul have prevented the most recent batch of compromised accounts, at least some of them anyway, would have been the password auditing that the WMF seemed to have agreed to do in the RFC that led to WP:STRONGPASS becoming policy, but as far as I can tell they never actually did one. Beeblebrox (talk) 18:46, 3 March 2017 (UTC)[reply]
I'll say that the reason I have yet to activate 2FA (I do want to), is that I switch accounts regularly and there is currently no 'remember this device for X days' feature here, which would make the process rather more laborious. When that option is added I will be happy to enable it. Sam Walton (talk) 14:45, 6 March 2017 (UTC)[reply]

I have enabled 2FA here at WP. Sorry I was so slow. There is an excellent article out there on general security improvements you may wish to look at, here is the URL medium article .... I want to say thanks to the newsletter editors for highlighting this. ++Lar: t/c 15:49, 9 March 2017 (UTC)[reply]

Thank you

A hearty thanks to all the editors who are involved in writing this newsletter - I really appreciate the effort and the result. I've always tried to keep up with policy and tech changes but that required keeping an eye on VPT, ANI, CENT, the open Arbcom cases and so on and on. Besides that monitoring these pages took quite some time I'd often miss half of the changes I was interested in anyhow so this quick monthly summary is definitely much appreciated. Excirial ^{(Contact me,Contribs)} 09:09, 1 March 2017 (UTC)[reply]

Same. I am not as active here as I once was and this newsletter is SUPER helpful, thank you very much, all who help do it... ++Lar: t/c 15:52, 9 March 2017 (UTC)[reply]

Cookie Blocks

Given how easy it is to clear cookies (and even the supercookie it also discusses setting) and the need to explain why people are blocked, (thus informing them of the cookie blocking) it wont take long for persistent vandals to figure out a way around this. I think it is actually a missed opportunity. If gave people cookies when blocked, and then included that cookie information in checkuser logs, it would be a powerful new tool to combat sock puppetry. While it wouldn't be secret per-say, it would probably go unknown to most sockmasters, unlike the blocking, where again, we will need to explain regularly how the potentially innocent editor got auto blocked. Monty ₈₄₅ 23:26, 1 March 2017 (UTC)[reply]

I think the cookie block is mostly aimed at the "casual vandal" who uses a mobile network or is aware that they can turn their router on and off to receive a new outbound IP. These people are the least likely to figure out how the cookie mechanism detects them, especially if we can just broom this under an "You are autoblocked because your system has recently been used for vandalism" carpet without explaining the actual mechanics at work. The entire cookie mechanism is essentially just security through obscurity anyway so i doubt that logging to the checkuser log would prove to be an effective sock puppeteer counter in the long run.

The cookie block is unlikely to be a magic pill that solves all vandalism issues, but it might prove to be quite effective against a specific group of drive-by vandals who vandalize and then try to gloat that they cannot be blocked. If the edit filter logs are any indication it would seem that editors tend to try the exact same edit multiple times before losing interest if they cannot get through. With some luck the cookie block will have a similar effect once an editor figures that a router reset isn't a free card out of jail anymore. Excirial ^{(Contact me,Contribs)} 00:32, 2 March 2017 (UTC)[reply]

This jives with my understanding of it. It's just another layer of abuse prevention to help deter "schoolboy vandals" not sophisticated abusers with WP:LTA pages. Beeblebrox (talk) 18:47, 3 March 2017 (UTC)[reply]