Yeah, I know, WP:PERENNIAL. But after yet another compromised inactive admin account ran amok over the project today, I feel like this should be revisited. The account in question did not have a logged action in over 2 years, and had made only 5 edits in 2017 and one in 2018. The policy as currently worded reads:

I propose modifying this to:

The change removes the notification requirement, and the "edits" criterion. The effect is that admin accounts which don't use admin tools for 12 months will simply have the bit silently removed as a matter of security. We won't tell them we're about to do it, and then they won't log in and make one nonsense edit to hang on to the bit. Removal will just happen when they've been away long enough, and if they come back some time later and want to go back to adminning they just ask at BN and go through the 24-hour hold like anyone else whose bit has been voluntarily removed. In fact admins should be actively discouraged from "holding on to the bit" in this manner, but let's at least do this. Ivanvector ( ^Talk/ _Edits) 17:51, 22 November 2018 (UTC)

Survey/discussion

• Support Given the length of time the inactivity policy has been around for now, I think it's reasonable to assume every active admin has heard of it, and nobody will be surprised if their rights expire, so provided this gets enough publicity in the right places, we should just do it. Also, as I just said on another thread, I think it would also be helpful to make two factor authentication mandatory for all admins, and desysop those who do not turn it on. It would stop this kind of disruption. Ritchie333 ^{(talk) (cont)} 18:09, 22 November 2018 (UTC)

I agree with the idea of desysoping (or at least warning) people for not using 2FA, but there would have to be some kind of cool-down period. Earlier this month, I had to get my phone replaced, meaning I went a day or so without 2FA. It simply wouldn't have been efficient to remove the bit for only 24 hours (especially because I was still active). Perhaps existing admins should get a month or two to set it up, all new admins get one week post RFA closure, and all admins that need to temporarily disable it also get a week. Anarchyte ( talk | work) 23:12, 22 November 2018 (UTC)

I strongly disagree with any forced 2FA idea. Forcing editors to have a certain device in order to be admins runs contrary to our most basic principles. There is no rational reason to preclude people unwilling or unable to use such additional devices from being admins. Especially since 2FA is still a hassle as Anarchyte points out and any problem with the device might render an admin incapable of editing at all. Plus, how many active admin accounts have been compromised? Regards So Why 11:58, 23 November 2018 (UTC)

I also strongly oppose mandatory 2FA. Benjamin ( talk) 01:12, 25 November 2018 (UTC)

Which part of our basic principles is it that requires insecure login methods?  — Scott • talk 15:42, 3 December 2018 (UTC)

As much as I think 2FA is a good idea, the fact is that requiring it would violate WP:5P3 (Wikipedia is free content that anyone can use, edit, and distribute). Administration is an essential part of running the project, and thus the ability to participate in administration needs to be available to anyone. Some people cannot afford to purchase the hardware required for 2FA. Some people are physically incapable of operating such hardware. Some people are not technically savvy enough to master its use. I would not be surprised if there were places in the world where possession of such hardware would be a crime, or at least expose you to unwanted government scrutiny. -- RoySmith (talk) 00:38, 19 December 2018 (UTC)

• Support though I fear that this is symbolic as all the inactive admins will come out of the woodwork to oppose. -- Rs chen 7754 18:15, 22 November 2018 (UTC)
• Oppose obviously seeing as not all admin actions are "logged" (for example edits to protected pages, statements in admin function such as WP:AE posts, "Stop this or I'll block you" threats and so on). Other projects which have such inactivity policies have had drama centered on whether non-logged admin actions count and there is the additional concern that such a policy would create an incentive to perform inappropriate but logged actions instead of appropriate but not logged actions. That, and I am sure we can count non-logged admin actions... Jo-Jo Eumerus ( talk, contributions) 18:13, 22 November 2018 (UTC)

  In that scenario (eg: "Hey, I was busy promoting DYKs from prep to queue, now I can't!") I think they should be able to get the tools back ASAP if they just ask at WP:BN. I'm not anticipating a rush. Ritchie333 ^{(talk) (cont)} 18:17, 22 November 2018 (UTC)

  Yes, but if they're actively doing things that don't get logged for twelve straight months they clearly not actively using the tools, and as Ritchie said they can just ask for them back. It's not a disincentive to adminning, it's purely a security feature. Ivanvector ( ^Talk/ _Edits) 18:53, 22 November 2018 (UTC)

  @ Ivanvector: be careful not to set up loop here as well - example: don't log anything for 12 months, then say "hey I'm back resysop me", then they don't use it right away - do we just pull it again? — xaosflux ^Talk 19:19, 22 November 2018 (UTC)

  Process-wise we would likely only review these once a month, for what it's worth. — xaosflux ^Talk 19:20, 22 November 2018 (UTC)

  Well, I'm not a 'crat, but I would say yes, create that loop. It's slightly better (security-wise) than the current loop of notify admin, "hey i'm not idle", then they spend another year idle with admin access. Ivanvector ( ^Talk/ _Edits) 19:57, 22 November 2018 (UTC)

  @ Ivanvector: perhaps you have considered this already, but significant areas of admin activity are not logged. Anything main page related, and anything related to editing restrictions other than blocks, will not appear in the logs. I know several admins who stick to main-page work. Vanamonde ( talk) 05:58, 23 November 2018 (UTC)

  @ Vanamonde93: yes, that has come up, there's a discussion about actions that aren't logged below. It is a very good point. Ivanvector ( ^Talk/ _Edits) 13:12, 23 November 2018 (UTC)

• Support both this proposal and the additional requirement for 2FA by Ritchie333 above. Brad v 18:19, 22 November 2018 (UTC) Striking 2FA comment, as that is not part of this proposal. Brad v 20:26, 23 November 2018 (UTC)
  • I agree with the 2FA requirement, but should that be a separate proposal? Jack N. Stock ( talk) 18:34, 22 November 2018 (UTC)
  • Yes, that should be a separate proposal and has been a few times. As I understand it 2FA is still considered "beta", and there has been significant pushback whenever anyone suggests it be required for any level of account. (The functionaries email list blew up over this very recently, and that's only a few dozen users) Ivanvector ( ^Talk/ _Edits) 18:55, 22 November 2018 (UTC)

    WP:INTADMINs are required to have 2FA but that is only because of a mandate from the WMF Galobtter ( pingó mió) 19:01, 22 November 2018 (UTC)

  • Yes, the 2FA requirement should be a separate proposal. And it probably is premature, as 2FA is not even available to non-admins yet. Brad v 19:02, 22 November 2018 (UTC)
• Support. We need to do something about all the hat collectors who refuse to give up their unused permissions. It's a security risk, and they can ask for their permissions back if they're actually doing something useful. NinjaRobotPirate ( talk) 18:27, 22 November 2018 (UTC)
• Support - TNT ^💖 18:52, 22 November 2018 (UTC)
• I'm curious how many administrators presently meet this criteria? – xeno ^talk 18:58, 22 November 2018 (UTC)

  @ Xeno: 288 per this list (including 4 'crats). — xaosflux ^Talk 19:05, 22 November 2018 (UTC)

• Ivanvector this should be an WP:RFC, and also on WP:CENT. Galobtter ( pingó mió) 19:02, 22 November 2018 (UTC)

Good point. RfC banner added, and I'll advertise on CENT as soon as I figure out how that works. Ivanvector ( ^Talk/ _Edits) 19:09, 22 November 2018 (UTC)

• Strong support This should be done to any account with advanced permissions, such as rollbackers and reviewers, not just admins. funplussmart ( talk) 19:05, 22 November 2018 (UTC)
• I suggest that this proposal should also modify the lengthy inactivity section to clarify that the clock for the three years of uninterrupted inactivity always starts with the last edit, and not with the last administrative action. isaacl ( talk) 19:05, 22 November 2018 (UTC)
• Support the original proposal per the nominator, oppose making 2FA mandatory. I'm presently unable to use it as my only compatible second device is away being repaired (due to an obese battery). There is also insufficient capacity at the WMF to handle users who have problems with it. Thryduulf ( talk) 19:31, 22 November 2018 (UTC)
• Oppose if you're going to get rid of the edit requirement then you need to have some sort of protection for admins who perform non-logged actions. We've had admins who only take part in admin actions that don't generate logs, such as editing the various bits of the main page. Such an admin would be desysopped even though they're still performing admin actions. Yes, they could ask for the admin tools back, but I don't see why they should have to every month just because of a badly drafted policy. Strictly this would also allow new admins and recently resysopped admins to be desysopped as well. Hut 8.5 21:01, 22 November 2018 (UTC)
  • I imagine the bureaucrats would just skip that admin each month, knowing that they are performing non-logged administative actions. As long as the number of these are low, it should be manageable. isaacl ( talk) 22:47, 22 November 2018 (UTC)
    • They might skip them, they might not. There would be no policy basis for doing so and bureaucrats tend to be keen on sticking to procedure. The more of these admins there are the harder it is to justify not desysopping them. The whole issue could be avoided by striking one word from the proposed policy change. Hut 8.5 20:37, 23 November 2018 (UTC)
      • @ Hut 8.5: I have no problem with that personally, but then we're asking the 'crats to take on the non-trivial work of judging which admins are active. There's a proposal below to implement a log for editprotected actions, so that editing a protected page will be a logged action and count toward activity with this wording. And viewdelete has come up but as I understand how filters work just looking at a deleted page is not something that can be logged, but so far a theoretical admin who only uses viewdelete is an extreme edge case. Ivanvector ( ^Talk/ _Edits) 20:55, 23 November 2018 (UTC)
      • Sure, I don't have an issue with removing the word "logged" from the proposed text. "may be desysopped" leaves the door open for judgment, but I agree that there isn't a need to limit the range of applicable administrative actions. isaacl ( talk) 21:00, 23 November 2018 (UTC)
        • I'd be happy to support this if the activity requirement was defined in terms of admin actions, where an admin action is something which can only be done by an admin and which shows up in your contribution history somewhere. That would include editing fully protected pages, closing discussions which have to be closed by admins, imposing discretionary sanctions and probably a few other things. I agree viewing deleted pages isn't enough and we can't verify it anyway. "Logged action" will be interpreted as something which shows up in Special:Log, which is more restrictive. Hut 8.5 21:42, 23 November 2018 (UTC)

  That's the intent, really: by "logged action" I mean "some action that requires admin permissions". Up until very recently (see below) I was under the impression all admin actions were logged in one way or another. Logging everything admins do is good for accountability, and also has this side benefit of being an indicator (by absence of log entries) of which admins are not actively adminning, and so I went with "logged action" for the policy wording. But it's just as well if it's wording meaning "any administrative action" as long as we have an unchallengeable definition (i.e. editing a protected page is, closing an RfC is not; it's something non-admins cannot do, not just something they shouldn't) and some way to measure it (i.e. logging, or maybe a bot to do the check, or calling on the 'crats to do it). Ivanvector ( ^Talk/ _Edits) 22:06, 23 November 2018 (UTC)

• Sounds like a use case for Wikipedia:Interface administrators. If an admin exclusively edits interface pages and has no interest in performing logged actions, then in the interest of security, they should not retain the entire administrator tool set - FASTILY 21:48, 22 November 2018 (UTC)

• Interface admin allows people to edit interface pages, not ordinary full-protected pages. Furthermore interface admins can do a lot more damage than admins and you have to be an admin to be an interface admin. Hut 8.5 22:04, 22 November 2018 (UTC)

• Support, and Support 2-factor authentication as well. I'd prefer 6 months, but as some admins seem to think 12 months means one month, that would only confuse them. DuncanHill ( talk) 21:05, 22 November 2018 (UTC)
• Strong Support. As Wikipedia's reputation and popularity continue to grow, it's imperative that we take security/user access controls more seriously. - FASTILY 21:51, 22 November 2018 (UTC)
• I support this too. Taking out the notifying part is a good idea. BTW Esanchez7587 should have lost the bit a year ago. Drmies ( talk) 21:57, 22 November 2018 (UTC)
• Oppose The Administrators are still using their account. — Eli355 ( talk • contribs) 22:19, 22 November 2018 (UTC)

*Support - We're not in 2006 anymore and this isn't a small fairly unknown website, We're currently the 5th visited website in the world and as such in this day and age account compromises really shouldn't be happening, But compromises can and do happen everywhere so we're not always going to be tiptop in that respect, Anyway I support the modification/update. – Davey2010 ^Talk 23:02, 22 November 2018 (UTC)

• Support - Not sure what I was going on about above .... but anyway admins logging in and making one logged-edit simply to keep their tools is ridiculous - If you're not actually going to help here then what's the point in keeping the bit ? .... so the silent removals (instead of notifications first) will hopefully stop this, As the saying goes: Use it or lose it. – Davey2010 ^Talk 12:37, 2 December 2018 (UTC)

• Support it’s not that difficult to make the trip to CAT:EX or CAT:G7 so the inevitable “people will make dumb actions just to keep the bit” thing falls flat. Opppse anything about mandatory 2FA. I use it, but we would lose several functionaries if we required it not to mention countless admins. TonyBallioni ( talk) 23:07, 22 November 2018 (UTC)
• Support - Not sure how long it should be, but the constant gaming by inactive−but technically active−admins is counterproductive. Anarchyte ( talk | work) 23:12, 22 November 2018 (UTC)
• Oppose. We want inactive admins to resume helping if and when they want to; there are life reasons someone may step away from the project, and not all will be willing to run the RfA gauntlet again as Opabinia regalis was. We don't want to encourage someone disaffected with the project but unwilling to surrender their tools to delete something or block someone just to keep them, even if it's an unquestioning response to a noticeboard request. Admins who do things like editing fully protected pages (not only DYK, but ERRORS comes to mind) are as useful as those who specialize in deleting and/or blocking, but the former don't appear in the easy to check log. (Nor does checking deleted contributions in evaluating how to speak to an editor, for that matter.) On the other hand I got lots of log entries for moving my own drafts to main space "without leaving a redirect". It's not a fair metric of admin activity. Desysopping for inactivity is also not an efficient way to protect against admin abuse: I recall one case where an admin ran wild including posting a philosophical musing to the Main Page. Emergency desysopping is the best strategy and less likely to lose us useful admins. And we already have that. I also recall seeing something about functionaries periodically testing admins' passwords for strength, but given other cases I recall, I doubt that's been being done. That would help (and would encourage those who don't have serious problems with two-factor authentication to take the step to get out of the resulting demands they change their single password). Also, admins are expected to have e-mail turned on; has any thought been given to bureaucrats' e-mailing those who don't appear to be using their tools, asking whether they would consider handing them in voluntarily? Yngvadottir ( talk) 23:17, 22 November 2018 (UTC)
  • There is no need to run the RFA gauntlet again if you return with 2-3 years, that bit wont change. Thryduulf ( talk) 23:22, 22 November 2018 (UTC)
  • ( edit conflict) Yngvadottir, I think you're misunderstanding the proposal. This isn't "anyone who doesn't use their admin tools for a year has to re-run RFA", it's "anyone who doesn't use their admin tools for a year has to post a request at WP:BN for them to be turned on if they decide to start admin-ing again, and the crats will automatically do so". ‑  Iridescent 23:23, 22 November 2018 (UTC)
    • @ Thryduulf and Iridescent: Ah. Thanks for clarifying. I've done some striking at the start. Yngvadottir ( talk) 23:32, 22 November 2018 (UTC)
• I would prefer to increase the requirement on what constitutes as "active". An editor who has six edits over two years should not be considered active enough to keep the tools. Mkdw ^talk 23:35, 22 November 2018 (UTC)
• Support Use it or lose it. The current requirement of needing a single edit in a calendar year is routinely gamed and far too low of a bar for retaining advanced permissions that can cause wide-spread disruption. Having read through previous related discussions I have never seen anyone present a compelling argument against implementing more stringent requirements.-- Jezebel's Ponyo ^{bons mots} 23:43, 22 November 2018 (UTC)
• Support We have nearly 80 admins who have edited in the last 12 months but haven't performed a logged admin action for over five years (in a few cases, ten). All of those, unless they're performing a large amount of non-logged actions - which I doubt - need to lose the bit. There's even a few there who have never passed an RfA .... Black Kite (talk) 23:59, 22 November 2018 (UTC)
• Support per nom and above supports. ZettaComposer ( talk) 00:53, 23 November 2018 (UTC)
• Support this system is easier to implement, prevents gaming, and has good rationale as per nom. -- Tom (LT) ( talk) 01:08, 23 November 2018 (UTC)
• I don't like the idea of -288 admins and -4 crats. I do like the idea of 2fa being mandatory. SQL ^{Query me!} 02:34, 23 November 2018 (UTC)
• Support. Removing privileges from admins who don't engage in any admin activity is a "paper loss", but a compromised account with privileges causes real harm. The standard proposed is still conservative and easy to meet. By comparison, some other WMF projects have requirements for admin actions every 6 months. (See meta:Admin activity review/Local inactivity policies for more information on other projects' policies.) -- RL0919 ( talk) 02:44, 23 November 2018 (UTC)
• Support. Re-requesting the bit if it's been removed is no big deal; compromised admin accounts meanwhile pose a much larger issue to the project. Home Lander ( talk) 04:18, 23 November 2018 (UTC)
• Oppose. First off - This is very premature. Difficult cases make bad law; it's always a bad idea to respond to an event by immediately trying to create a policy that will prevent its recurrence. There has not yet been an analysis of what was going on here. We don't actually know if this is a compromised account; really, what we have is an admin account that acted in an unacceptable manner. Conclusions have been leapt to, and they have not yet been proven. Second - there's no evidence that this change will prevent future similar episodes. The vast majority of administrator accounts that required their privileges to be yanked were those of administrators who would easily have met these more stringent standards, let alone the current ones. Come back in a month, with greater research and good evidence that the proposal will likely prevent rogue administrator actions, and then we can talk. Risker ( talk) 04:40, 23 November 2018 (UTC)

  We do know that the account was compromised ( related phab task) but otherwise agreed that knee-jerk reactions aren't the way forward here. -- Ajraddatz ( talk) 05:14, 23 November 2018 (UTC)

(Unfortunately the task is not visible to the public.) — regards, Revi 05:17, 23 November 2018 (UTC)

What we do know is that the same person has compromised (or at the very minimum, abused) 16 other accounts. [1] Personally I've no doubt about it. -- zzuuzz ^(talk) 07:20, 23 November 2018 (UTC)

Well, since Ivanvector below has indicated that this proposal isn't really about the recent admin account hackings, and it seems to now be understood that this wouldn't prevent hacking in the first place, I'd be willing to consider an increase in the activity levels of admin accounts. However, I do see lots of useful admin activities that are not logged. If there is to be a change in threshold for de-adminning, I'd go with any combination of X number of edits and Y number of logged admin actions within the previous 12 months, where the total of X+Y equalled some specified number; for example, there must be a minimum of 10 actions (either edits or logged admin actions) within the past year. I strongly believe, however, that the notification of a user that they are on the verge of losing their admin tools is absolutely mandatory; I actually don't understand why anyone would think it was okay not to do so. And it seems there is an agreement that 2FA is off the table too, which is a good thing, since it's really out of the control of a single project. Risker ( talk) 02:25, 24 November 2018 (UTC)

It is about the recent hackings, but not meant to be a solution to that problem, just mitigating risk. If the idle hacked accounts had not had admin access then probably the hack would have just taken another form, the vandal has also been hacking accounts that only have rollback permissions. As for the notification requirement, my rationale for changing it is that in the policy's current form we let admins be entirely idle for an entire year, then we tell them to make one single edit if they want to hang on to the bit for another entire year, and in my view that entirely defeats the purpose of suspending the rights of inactive accounts. We might as well just not have this policy at all. If we alter the activity requirements instead, that could be an alternative to this proposal, but given that so many have already commented here on the original I think it would be a good idea to break that out into another subsection. Ivanvector ( ^Talk/ _Edits) 14:58, 24 November 2018 (UTC)

Well, since it *is* about the recent hackings after all - and given the fact that as I write this I am currently investigating the most recent compromised admin account (of an administrator who is highly active)....this entire discussion is moot. This isn't going to stop the vandal involved, and I don't think it reduces risk whatsoever. Risker ( talk) 20:33, 24 November 2018 (UTC)

• Oppose Having to ask for my bit back every month because I only edit protected pages is not an ideal scenario. Step hen 05:08, 23 November 2018 (UTC)
• Oppose - As a semi-active admin (but not one who would currently be desysopped under this proposal), I can't support this. I don't believe that the risk of rogue admin actions outweighs the harm to the project that would be caused by driving away semi-active admins who have put in a lot of time and edits, even if real life is preventing them from logging admin actions right now. In addition, desysopping without even a notification is cruel. - Danaman5 ( talk) 05:39, 23 November 2018 (UTC)

"Cruel"? I had my admin rights on Monochrome BBS removed without asking sometime around 2002 (I couldn't even pinpoint the year, which is kind of the point) because of inactivity. All I said was "it's a fair cop". Ritchie333 ^{(talk) (cont)} 12:05, 23 November 2018 (UTC)

• Support Not really about security, because I feel that's a non-issue overall. But I have long thought this policy needed tightening up to stop people "playing the game". I would change it slightly though, to remove the word logged, so removals should be based on any edit or log which required admin status. Aiken D 06:37, 23 November 2018 (UTC)
• Oppose I was going to say what Risker said, but she already said it, so I can just say "what Risker said" ;) We can't just stop informing people of changes that concern them because we don't want them to actually act on that information. Adding to that, I always have a negative reaction to the tone of some of the comments in admin-activity discussions - there's always a lot of snippy posts about "gaming the system" and "hat collecting" and whatnot. Every time I point out that that was me at one point, I almost certainly would have done the "log in and make an edit or three" thing if I'd seen the messages while I wasn't active, and it would have been entirely due to thinking "oh yeah, it's been awhile, I should get back into that when I get some spare time" and then not following up due to, well, lack of spare time. And based on that the same stuff gets posted every time, it seems that pointing out that there's a perfectly reasonable good-faith thought process behind this behavior has exactly zero demonstrable impact on people's willingness to make kind of mean-spirited assumptions. That's not a reason to oppose on its own but it's a weird and off-putting pattern. *shakes fist at cloud* Opabinia regalis ( talk) 07:10, 23 November 2018 (UTC)
• Question: What's the escalation plan for two years or so from now, when the new moral panic is about admins who create and then speedy a page in their userspace once a year? — Cryptic 08:25, 23 November 2018 (UTC)
• Support By definition, by not editing/doing an admin log in 12 months means they are not an admin! Lugnuts ^{Fire Walk with Me} 08:54, 23 November 2018 (UTC)
• Oppose, far too many "things only admins can do" don't appear in the logs. We need more admins not less. Fish+ Karate 09:25, 23 November 2018 (UTC)

  And I will note this RFC has not been written neutrally. "Yet another admin account" implies this happens frequently; per Wikipedia:Former_administrators/reason/compromised, the accounts of Denelson83 and Esanchez7587 have both been compromised this year, but the last one prior to these two was in 2012. Nine compromised admin accounts in 12 years is not frequent. "Ran amok over the project" - they made zero edits and 12 administrative actions, 10 of which were blocks, all of which were undone within 33 minutes. Emotive language doesn't help anyone. Fish+ Karate 09:44, 23 November 2018 (UTC)

  In 2016 quite a few admin accounts were hacked by OurMine (see [2]) and they're not listed there in former administrators because they recovered their accounts (see e.g this for locking and unlocking) Galobtter ( pingó mió) 10:03, 23 November 2018 (UTC)

  And in 2015, a few accounts were compromised by an attack elsewhere, including two admin accounts. I can agree with the wording being a little iffy, though it's a little more understandable after these are factored in. Anarchyte ( talk | work) 10:11, 23 November 2018 (UTC)

  Thanks both, I was not aware of these. This takes it to 14/15 or so admin accounts in 12 years, unless there's others still unlisted, which still doesn't strike me as a regular occurrence to the point 2FA has to be imposed on everyone. Fish+ Karate 10:52, 23 November 2018 (UTC)

The reason they didn't appear to "run amok" after indef-blocking two long-standing users who tried to stop them is that a bunch of people scrambled around to get the issue fixed ASAP. As Anarchyte has mentioned, The page above does not document the incident where Salvidrim and OhiaUnited were compromised, or when Jimbo Wales' account was cracked and ran amok, for example. We need a full set of figures to be able to look at the facts correctly. Ritchie333 ^{(talk) (cont)} 10:20, 23 November 2018 (UTC)

These stats also don't count the several steward and functionary accounts that were also hacked recently, which could have caused serious actual harm (but AFAIK didn't). Not that this proposal would do much for those levels of permissions, I'm just saying this is quite far from an isolated incident. Ivanvector ( ^Talk/ _Edits) 13:11, 23 November 2018 (UTC)

• Support- regardless this latest trigger issue. Not one iota of valid argument in any of the opposes so far. Leaky Caldron 10:15, 23 November 2018 (UTC)
• Support Everyone can edit, but only admins can make admin actions. Thus their level of activity should be judged by the amount of admin actions they make. I fully understand that some of these actions are not logged, but I don't view this as a reason to oppose. talk to !dave 11:15, 23 November 2018 (UTC)
• Conditional Support on the basis that an edit filter like the one Xaosflux proposes here (or some other solution) is adopted, so that all major onwiki admin actions are logged. Iffy★ Chat -- 11:37, 23 November 2018 (UTC)

  @ Iffy: These could be logged for bot review (see example on testwiki. — xaosflux ^Talk 14:45, 23 November 2018 (UTC)

• Support protection of the project clearly outweighs putting a legacy admin to the trouble of requesting their tools back occasionally. —— SerialNumber 54129 11:48, 23 November 2018 (UTC)
• Oppose I wish people were pouring effort and creativity into keeping the editors and admins we have. Rogue accounts are easily dealt with. Making people go through any kind of hoop at the end of inactivity is an unhelpful additional barrier to their return. -- Dweller ( talk) Become old fashioned! 12:25, 23 November 2018 (UTC)
• I'm all for increasing the activity requirement for security purposes. At the moment it's anything greater than 0 activity. I'm not sure that greater than 0 admin activity is the right way to go - I'd be more keen to look for say, 50 edits per year. It will stop those who keep dormant accounts alive by making a single edit, yet should be easy to reach even at 5 edits per month, which is our definition of "active". Perhaps have 50 edits per year or 1 admin action per year? Regarding mandatory 2FA, I oppose. largely per Risker's diversity concerns. Worm^TT( talk) 12:28, 23 November 2018 (UTC)
• Oppose. (Disclaimer; this provision would have caught me out on multiple occasions.) The whole "reduce the potential for compromise" thing, I'm assuming is a complete red herring, unless anyone can provide any actual data to indicate that "admins who have edited within the past 12 months but haven't performed a logged admin action in that period"—the only group which would be affected by this proposal—are at any more risk of compromise than any other account. I'm a strong opponent of the current setup which allows legacy admins from the early days of Wikipedia to periodically emerge and start trying to enforce the standards of a decade ago, and would support some kind of periodic reconfirmation, but I don't see how this proposal would address either the security or the legacy admin issues. (What's to stop either a compromised account, or an incompetent legacy admin, from heading over to WP:BN and asking for the sysop bit back?) In all honesty, whatever the good intent of the proposers it looks more to me like an attempt to cull the number of admins via the back door. ‑  Iridescent 12:32, 23 November 2018 (UTC)

I don't particularly disagree with anything you've said here, but let me try and clarify my view on this. As I vaguely mentioned above, the inactivity standards here seem to be far higher than anything else I've personally witnessed - I've been the equivalent of desysopped for inactivity elsewhere without complaint (but perhaps I'm just the sort of person who shrugs shoulders and moves on) and when I was a regular on Monochrome BBS in the 1990s, policy was that if you didn't use any account (ie: basic user privs) for three months, it was deleted. Is that a good or bad thing, or just different? Secondly, I do think "culling the number of admins via the back door" is a fair point, and I think part of that is due to the dissatisfaction over "legacy admins" because it's too hard to pass RfA these days. Indeed, one of the reasons I went looking for admin candidates over the past 12 months was simply to try and dilute some of that, so that we had a fresh corpus of new admins bringing new ideas into the place, rather than having to rely on people with a grandfather clause. As for what else can do about that, I don't know. Ritchie333 ^{(talk) (cont)} 12:49, 23 November 2018 (UTC)

• I'm in a weird place here — In a vacuum I don't dislike the proposal, but a few of my "always agree with" editors have opposed, so per usual I'm in agreement with them. I like the policy change, if only because it will increase the churn and make it clear that +sysop isn't that big of a deal. I'm not concerned about unlogged sysop actions (although regardless of this the edit filter may be a good idea) because it should be easy to head over to BN and say "Yo, still sysoping here" and get the required bit back. That does, however, belie my real issue with this, which is that it doesn't solve the problem of compromised accounts. A user who is occasionally editing without any logged actions is no less likely to be compromised as they are indeed still using the account. I can support more stringent activity requirements, but I can't support this on the grounds of trying to solve compromised sysop accounts. Put more succinctly by Eli355, [t]he Administrators are still using their account. ~ Amory ( u • t • c) 13:18, 23 November 2018 (UTC)
• Yes, but Only if DYK/Protected Logged - we frequently see DYK as a primary reason for suffering going through RfA, and protected edits must also count. I am in favour of this but at a minimum we need DYK logged and probably any protected edit tagged. Nosebagbear ( talk) 13:49, 23 November 2018 (UTC)
• While I don't want to be one of those "old" admins coming out of the woodwork to reflexively oppose, I think I'm going to oppose. De-adminning for inactivity makes sense to me - if you don't log in for a long time, you may not know what's going on, and you may not be paying enough attention to your account to be sure it's secure. I could support reducing the window of inactivity in the project at all, but I'm not convinced that de-adminning for disuse is the right way to go. What the project needs isn't fewer admins - it's fewer inactive admins. So rather than quietly taking about the tool, why not nudge people to use them more? Something like a bot message that says "you have not made a logged admin action in the last 6 months. Here are some clean-up tasks you could help with". Maybe after a year, up it to "you haven't made a logged admin action in the last 12 months. Please drop by BN to confirm that you still want the tools". Sure, some people are going to make some logged actions just to hold onto the tools, but for every one of those, there would probably be 10 or 20 people who would say "you're right, let me help out a bit". At the very least, I think we should try to nudge people into activity instead. See if that works, before we go ahead with a proposal that, let's be honest, assumes bad faith on the part of inactive admins. Guettarda ( talk) 14:17, 23 November 2018 (UTC)
• To be honest I'm surprised that so many editors are commenting here that this RfC is an attack on inactive admins. It's not, not at all, and I'm a little bit offended that it's being interpreted that way. It's purely patching a security vulnerability. Think of it like the front door of your house (apartment, dwelling, whatever). You have some friends over, you have a good time, eat some food, drink some beers, play some games, whatever. Then everyone goes home, and you close the door. You're still friends (presumably), they're still welcome in your home, but you don't just leave the front door open for when they come back (or you don't in this climate anyway). When they do come back, you look out your window or peephole or whatever, confirm it's your friend knocking on the door, then you welcome them back, eat some beers, drink some food, whatever it is you do for fun. That's all that this is. If an admin has been away for a while, they're still an admin, we just take their mop and hang it back in the closet while they're not using it. It's their mop, and when they ask for it back we gladly hand it back over, and then a bunch of people drop by WP:BN and leave notes like "hey welcome back! we missed you!" It's not a back-door desysop at all.

As for solving compromised admin accounts, of course this doesn't, it doesn't even really try to. As long as we have admins we're going to have hackers trying to crack admin accounts; some of them are inevitably going to be successful, and that is not the admin's fault. All this does is cut down on the number of doors left open to Wikipedia's house. And sorry for the crude analogy. Ivanvector ( ^Talk/ _Edits) 15:29, 23 November 2018 (UTC)

• CommentI am not an admin so maybe there is something I am missing, but how does this helps security. Is there any difference in using your account to make admin actions or edits in terms of judging activity and the likelihood of an account to be compromised. Using Ivans open door comparison, you are just as likely to open your door to a friend who has come over for an informal chat as you are to your same friend who comes on some formal visit. They have still visited, even if it is only once a year. If it really is necessary to tighten security via counting actions I feel it would be better to shorten the time of inactivity or increase the minimum number of edits per year. AIRcorn  (talk) 17:34, 23 November 2018 (UTC)

  I think the main goal is to reduce the attack vector; less admins means less accounts vulnerable to be compromised, and accounts largely inactive are likely that of users who may not be around to get the reminders and improve their passwords (noting another admin just got compromised.. last admin action in 2014) Galobtter ( pingó mió) 19:45, 23 November 2018 (UTC)

• Support, seems like a sensible reform. GAB ^gab 18:20, 23 November 2018 (UTC)
• Oppose the change per Risker and Iridescent. Particularly with the attempt to backdoor force 2FA for admins. ♠ PMC♠ (talk) 19:55, 23 November 2018 (UTC)

Oh, hey, just back from another cleanup from another compromised admin account. There is no "attempt to backdoor force 2FA for admins" going on here. I don't know how to more clearly or bluntly state that 2FA enforcement is not going to happen. If it does it will come from the WMF and we'll have no say in the matter. It's just not part of this proposal at all. Ivanvector ( ^Talk/ _Edits) 20:19, 23 November 2018 (UTC)

@ Ivanvector, the very first comment in the thread is make two factor authentication mandatory for all admins, and desysop those who do not turn it on. You can legitimately say that you don't agree with the attempt, but don't try to claim the attempt isn't being made. ‑  Iridescent 12:55, 24 November 2018 (UTC)

There is always some background minority push to do some thing that is widely not supported or technologically impossible. Mandatory 2FA for admins is one of those rare things which is both not widely supported and difficult technologically to implement (WMF's implementation, not necessarily 2FA in general, see Risker's comments among others). I view the attempts to wedge mandatory 2FA into this completely unrelated proposal as hijacking the thread, and I wager I am more angry about it than you are. Ivanvector ( ^Talk/ _Edits) 14:13, 24 November 2018 (UTC)

• Oppose - Some form of removal notification is due, and it is possible to use the tools for the benefit of the community without logging any administrative action (e.g. viewing deleted page history). —  Godsy ^{( TALK} _CONT) 20:08, 23 November 2018 (UTC)
• Support If you are not using the tools, you will not miss them. If you do want to use them, all you have to do is ask for them back. It's a small hoop to jump through for the sake of fewer sysop account with the potential to be compromised. The benefits to the project outweigh the inconvenience to any very infrequently active admins that this would affect. Natureium ( talk) 20:27, 23 November 2018 (UTC)

• Comment - We've had another cracked admin account this evening, no logged activities for four years, vandalised the main page, deleted today's featured article and indeffed a bunch of admins. Does this influence anyone's opinion? Ritchie333 ^{(talk) (cont)} 20:33, 23 November 2018 (UTC)
• Support The base proposal without requiring 2FA. It should remain a strong recommendation though. Also support "logged actions" being extended to use of editprotect and tracked via the edit filter mentioned above. — AfroThundr ^{( u · t · c)} 20:49, 23 November 2018 (UTC)
• Support The time for pearl clutching is OVER. 2 compromised accounts in a few days is unacceptable. Furthermore it will make the Mop Holder "Put up or Shut Up". Either they do have a need for the admin toolset (or can relatively easily get it back) or they don't need the tools any more. I agree with the provisos regarding certain unlogged items that should count as activity (though why we couldn't get those logged as admin activities is annother question). I note that previous attempts to get admins to maintain secure passwords (or 2FA) were turned down as beyond scope, however the outbreak of compromised administrator accounts requires us to exercise the more painful choice. Hasteur ( talk) 22:27, 23 November 2018 (UTC)
• Support Long overdue. The counterargument that not all admin actions are logged, while technically true, is a red herring. If you are only using adminship as a status and to peek at deleted material, you aren't doing an admin work. With two inactive accounts compromised in as many days it should be abundantly clear that this is needed. The policy will still be quite lax. Beeblebrox ( talk) 23:46, 23 November 2018 (UTC)

• Support - There are too many Admins gaming the system by making one edit a year to keep hold of their Admin bit when notified, and not making one Admin action for several years. It is about time we use common sense and stop this charade. JMHamo ( talk) 00:23, 24 November 2018 (UTC)
• Oppose When I first started reading I was intending to support. However, after reading some comments above, specifically Cryptic's about there still being a very easy loophole to keep the tools. The only counter to that is not telling admins that there tools are about to be yanked might work the first time, but, after that it won't be difficult to add a yearly reminder to create then speedy delete a userspace page. This would be especially easy to circumvent if edits to protected pages count as admin actions for this proposal, as one edit per year is still all that's required, it'd just need to be to a protected page instead of any page. Perhaps it might be better to increase the number of edits and/or logged actions are required to keep the tools. Callanecc ( talk • contribs • logs) 01:04, 24 November 2018 (UTC)
• Support - Per nom, remove irresponsible "gaming the system" and just plan account security. - FlightTime ( open channel) 02:44, 24 November 2018 (UTC)
• Support The comments about unlogged admin actions, moral panic, and suggestions of how an admin could game the system miss the point which is that reducing the attack surface is the first principle of security. That's all. Unlogged admin actions can be solved with a cratchat to establish an exception for a particular case. Concern about biting inactive admins can be solved by crafting a good message thanking them for their work and letting them know they can easily regain the right. That process should emphasize the need to have a unique password. Almost certainly the hacking of several admin accounts in the last couple of years was done by people matching the list of admins with lists of user accounts hacked on other websites and finding cases where the hacked password was reused at Wikipedia. Admins who are genuinely active are much more likely to have thought about security and we can hope they use a unique password. Johnuniq ( talk) 03:03, 24 November 2018 (UTC)
• A further suggestion: how about not calling it "desysopping", but something like "suspension of administrative rights"? The admin in question is not being removed from the administrator corps, and can continue to do all the same administrative actions as before that do not require administrative rights (including deciding not to take any actions). Should the admin wish to take an action that requires the administrative rights, an extra step of requesting that administrative rights be re-enabled is needed. isaacl ( talk) 03:21, 24 November 2018 (UTC)
• Support This is a political question, and I'm strongly in favor of there being more situations where admins have to say hello at WP:BN after a moderate duration absence from regular activity, or re-RFA after a longer one. I do agree with the concerns that editing the various full-protected transclusions of the Main Page should be tracked as admin actions for inactivity measurements if this is implemented; the case that an editor only edits other full-protected pages is unlikely enough to be ignorable. power~enwiki ( π, ν) 03:30, 24 November 2018 (UTC)

  I must note that I don't see the security concerns as a good reason to support this, though it's a plausible excuse to re-start this perennial discussion. A more effective way to handle security concerns would be to inform all admins who haven't changed their password since 2013 that they have 30 days to change their password to one that meets security guidelines, or they will lose their admin privileges. Simply reducing the number of admins does nothing good (I concede we could completely avoid the risk of hacked admins by having no admins at all); this proposal acts as a (weak) proxy for reducing the number of admins who have insecure accounts, which is what is needed. power~enwiki ( π, ν) 03:30, 24 November 2018 (UTC)

  Is there a way to force password change, maybe in LocalSettings.php, say every 90 days or whatever span of time ? - FlightTime ( open channel) 03:47, 24 November 2018 (UTC)

  I note you're both making an assumption that passwords created in 2013 or earlier don't meet current security guidelines, or assuming that the security guidelines should include mandatory password changes. You may want to read https://www.ftc.gov/news-events/blogs/techftc/2016/03/time-rethink-mandatory-password-changes about the latter. (P.S. Yes, mw:Manual:$wgPasswordExpirationDays exists) Anomie ⚔ 15:49, 24 November 2018 (UTC)

I'm no assuming anything, I was merely asking a question. - FlightTime ( open channel) 23:25, 24 November 2018 (UTC)

• I don't assume that all early passwords are weaker, but I believe the software-enforced minimum password strength has increased over time (if you believe all the comments here, at one time 1-character passwords were allowed, and that certainly should not be allowed). Forcing everyone to do a one-time password rotation might be a better option. I don't support a mandatory 90-day expiration period; in my professional experience in the technology industry rotation periods of less than 1 year are almost always harmful in improving security. power~enwiki ( π, ν) 16:15, 24 November 2018 (UTC)

• Oppose - As others have said, there are admin actions which are not logged. There are a lot of permissions in the admin toolkit, and most are not logged, and many are of indirect, rather than direct use. This has been stated in every one of these discussions. that fact hasn't changed. Plus there are things admins do which require access to certain tools, but which may not need their actual usage in that specific instance. Such as closing a deletion discussion. Also, we prefer admins to embody restraint in regards to tools. This sort of proposal will just cause people to think they shouldn't act with restraint. And besides that, we'll start seeing logs bloat with barely accountable actions. Want an example? Handing out rollback is something an admin can do. And hey, it's even logged! So every admin just goes and gives rollback to someone. And to really make it fun, give rollback to an inactive admin... Tell me what's been solved? And finally, the moment an admin account has been compromised, wouldn't the compromiser immediately do an admin action? And so wouldn't that pretty much void the justification for this proposal? This may be a well-meant proposal, but it just really is a bad idea. - jc37 04:38, 24 November 2018 (UTC)
• Support - Given recent events, this proposal is more than necessary. A year without a logged action is an enormous window, and any affected admin can just pop over to WP:BN and ask for the bit back. Nathan2055 ^{talk - contribs} 05:23, 24 November 2018 (UTC)
• Strongest possible oppose Does it ever occur to you that not all of us have smartphones and never plan to have them, so not all of us have the option of 2FA? I don't really have an opinion on changing the activity requirements, but don't take away my user rights as long as I'm using them in a proper fashion. Period. Nyttend ( talk) 05:45, 24 November 2018 (UTC)

  Nyttend, 2FA isn't actually part of this proposal. I apologize for my earlier comment conflating the two ideas, but this is only about the activity requirements. Brad v 05:47, 24 November 2018 (UTC)

  And 2FA doesn't need a smartphone anyway - there are 2FA apps for computers too. Boing! said Zebedee ( talk) 08:15, 24 November 2018 (UTC)

• Support. - There are a few pretty egregious individuals, basically NOTHERE administrators, if you will, who do a couple bland edits a year to retain tools. We need to get a handle on how many or few administrators there actually are, and these phantoms impede an accurate assessment. Carrite ( talk) 07:57, 24 November 2018 (UTC)

Just wondering - what's wrong with that? -- The Cunctator ( talk) 15:17, 4 December 2018 (UTC)

• Support. As others have opined, if you're not going to use the admin tools then you shouldn't have them. And it's easy enough to restore the bit to someone who is genuinely going to use it. I'll just add that my opinion is not related to the recent hacks, it's a view I've held for a long time. Boing! said Zebedee ( talk) 08:18, 24 November 2018 (UTC)
• Support disabling inactive rights is basic risk management in any it organisation. Doing one or two dummy edits a year is WP:GAMING of the inactivity rule and shouldn't be encouraged. -- Pudeo ( talk) 09:04, 24 November 2018 (UTC)

• Agree that gaming the system is a problem. Disagree with the proposed solution to the problem of not notifying the inactive admin. The right way to deal with this is like we do with 3RR: an editor who repeatedly waits until just after the 24 hours is still treated as an edit warrior. Likewise, we can treat any pattern of dummy edits that are clearly designed to avoid the inactivity rules as we would treat any other inactivity. -- Guy Macon ( talk) 09:41, 24 November 2018 (UTC)

• Support any proposal to tighten admin standards and accountability. feminist ( talk) 09:55, 24 November 2018 (UTC)
• Oppose This proposal as drafted risks exacerbating a bigger problem than it seeks to address. Our problem of admin retention is much much more serious than any problem that the current proposal is hoping to mitigate, and auto desysopping makes Wikipedia less welcoming for returning admins. I would be more relaxed if this was a more nuanced reform with the period of time that old admins could return after increasing and the introduction of a meaningful test for such returnees. For example one day of renewed activity (not necessarily contiguous) per year of absence, up to a maximum of ten years since being desysopped for inactivity. That would give the community a reasonable chance to assess if the returnee had remembered/refreshed and updated themselves about Wikipedia, and showed enough commonality and experience that they were likely the same person. Ϣere SpielChequers 13:43, 24 November 2018 (UTC)

• Why do we need to retain an admin who performs 1 admin. action a year? They are not productive in any meaningful way and simply inflate a headline Admin. count which does not reflect true productivity in anyway. Rather like many of the stats. you churn out from time to time, it is a meaningless total when a large number do next to nothing. Leaky Caldron 14:27, 24 November 2018 (UTC)

• Actually I'm not interested in retaining as admins those who only ever do one or two admin actions a year. I'm interested in retaining and keeping an open door for formerly active admins who might become active admins again in the future. such as retaining/reactivating more of the formerly active admins who return here after long periods of time. The problem is that once someone has dropped to a very low or zero level of activity we currently have few tools to tell who might return in the future and who will never return. So I've no problem assuming that those who have died won't be back, but with the project not quite 18 years old we have no way of knowing how many adolescents who go inactive after less than a decade of activity will return once they have retired, or before. We don't yet have anything close to a figure such as "after x years of inactivity the chance of return approaches zero". Ϣere SpielChequers 17:07, 24 November 2018 (UTC)

• Support This is a simple, non-punitive way to keep our admin roster at least a little bit up to date. Powerful tools should not be attached to inactive accounts, that's all. If people aren't using WP at all, they should not have admin tools. If they are only logging on once a year because they got an email warning, they should also not have admin tools. I agree with the proposal as written, with the one addition that a note should be put on their user talk page, AFTER the desysop, explaining what happened and why, with the assurance that it is just a security measure and does not reflect any wrongdoing on their part, and they can get their tools back via a simple request at BN. -- MelanieN ( talk) 15:23, 24 November 2018 (UTC)

P.S. I very much like Isaacl's suggestion that such action be called "suspension of administrator rights" rather than "desysop". -- MelanieN ( talk) 15:31, 24 November 2018 (UTC)

• Oppose the wording as written above. There are plenty of times where I have been an active administrator even though I didn't use "logged administrative actions". Especially when I'm engaged at WP:AE, my preference is to do unlogged actions such as warnings, rather than blocks. I'm not opposed to tightening up the policy in other ways, like if someone has fewer than 10 edits per year, that might be reasonably viewed as inactive. Then again, if those edits are at administrator pages such as WP:ANI, WP:AE, comments at ArbCom pages, or anything in the Wikipedia space (as opposed to user/article pages), then I would see that as being more active. -- El on ka 22:25, 24 November 2018 (UTC)
• Support, sans 2FA and with the "suspension" wording. I've thought about this very carefully, particularly because I take the oppose comments by Risker and Opabinia very seriously. And I would be opposing if, hypothetically, the proposal were to require a new RfA. But posting a message at BN and waiting 24 hours – that's hardly a burden. I do agree with Ivanvector's analysis of partially reducing security risks (no need to let the perfect become the enemy of incremental improvement), and also with the view that we really expect active admins to be able to easily satisfy the revised requirements. Wikipedia is simply not the website that it was a decade ago. In some ways, we should expect more "professionalism" from all editors, but certainly this isn't an imposition on those users who want to have advanced permissions. -- Tryptofish ( talk) 22:46, 24 November 2018 (UTC)
• Support - Regardless of the recent activity, this would be a good policy. "Retaining" admins who do not participate isn't retention. Onel5969 ^{TT me} 23:18, 24 November 2018 (UTC)
• Oppose per Dweller. Kaldari ( talk) 00:46, 25 November 2018 (UTC)
• Weak Support As the incident involving Killiondude demonstrated, this can happen to anyone, and isn’t only limited to inactive admins. I support this only for the fact that it might be a more effective deterrent to a black hat trying to get access to vulnerable admin accounts. OhKayeSierra ( talk) 01:03, 25 November 2018 (UTC)
• Support tightening desysopping (or "suspension") rules though there is probably a better way to get around admins who may attempt to "game the system" by speedying a bullshit page they create in their userspace so they've technically logged an "admin action". Of course, if an admin just wants to keep the tools for fun rather than to use them constructively to improve the project, it reflects poorly on their suitability for having the bit in the first place, not to mention the security concerns discussed many times above. IntoThinAir ( talk) 01:40, 25 November 2018 (UTC)
• Support The potential for an admin who performs non-logged actions being de-sysoped is a non-starter for me. All it takes to stop that from happening is to do a 2-minute drop-in at requests for page protection once a year. The amount of time expense to do that is less than the amount of time expense to clean-up after a compromised account. Chetsford ( talk) 05:26, 25 November 2018 (UTC)
• Strong Oppose - I find the removal of a notification requirement to be a non-starter and contrary to our basic principal that someone should be notified before an action is taken against them. If someone is inactive, it does not mean that they will not come back nor that they cease being a member of the community. As someone who tends to come and go (and is also an admin) even if I'm not fully active at a given period, I do make occasional edits, maintain a strong, secure, and unique password, and see all messages (via notification and email) especially because I run a few bots. Further, the requirement for a "logged administrative action" as opposed to just editing seems to go against the spirit of us being here to build an encyclopedia and the goal that the appurtenant bureaucracy should just be ancillary. If someone is editing without using the tools it does not make them any less trusted or capable of using them responsibly them when they do need to use them. Further, administrators can, and do, add value by helping at WP:DYK (where I personally do quite a bit of work), WP:EDITREQ, and in other places where the tools are of value or essential even if their use is not formally logged. Finally, I agree with Risker's comments above and do not believe that this will meaningfully increase security. If we want to increase security, the strength of your password, it not being reused elsewhere, and 2FA (current technical issues and lack of support notwithstanding) are much, much more important to look at than activity. Regretfully, it looks like the group targeting admin accounts has enough sophistication to understand a bit of our inner workings, if an outside actor were to compromise a highly active admin account (as has happened before), all they would need to do is wait for the user to be offline or asleep to act. Our default edit counter (shown at the bottom of each user's contributions page) even has a "timecard" feature (see here for mine) which graphically shows a time distribution of your edits. Even if we were to disable this feature, it is not hard to figure out when I, or any other user, is almost never online. While I strongly agree account security, especially for accounts with advanced permissions, is essential, I cannot support this as I do not believe it helps us move towards additional security and am deeply concerned it could drive away valuable and respected editors and make it harder for them to return (similarly as Dweller pointed out above). Best, Mifter ( talk) 06:27, 25 November 2018 (UTC)
• Weak Oppose I want a solution that 1. fixes this problem and 2. doesn't feel punitive to good-faith admins who for whatever reason are inactive for a while. I'm not sure this proposal does either of those things. If we want to prevent hackable accounts causing problems, require ALL admins to change their password regularly. And is there any way to show on the password reset page the results of that little handy tool Guy Macon links to below? If admins are told when they reset their password how hackable their password is, and just how attractive a target WP is, I would assume good-faith admins would go ahead and create an unhackable phrase rather than coming up with yet another version of pa55w0rd. And if after that they still do create a crap password and get hacked, THEN they get punished lol valereee ( talk) 12:21, 25 November 2018 (UTC)

• The tool at http://rumkin.com/tools/password/passchk.php might be a better choice. That checker is The code is licensed under the GPL, so we are free to use it. -- Guy Macon ( talk) 16:33, 25 November 2018 (UTC)

• Support. Inactive bits must be frozen. But given the number of administrators who are not convinced that security issues could be more than a "set-up to thwart Ivanka" ... we will probably have to wait for a big drama, followed by panic countermeasures imposed by SanFran. Pldx1 ( talk) 14:43, 25 November 2018 (UTC)
• Support. I would want admins to be actively using their tools, but I disagree "logged actions" being the cut-off. Instead, I would want to extend this to any activity that could not be performed by a non-admin. I would want to have a notice given for admin accounts that are performing edits on a semi-regular/regular basis for the impending removal of rights, but for completely inactive accounts the notices seem unnecessary. Only providing notices to accounts with more than just a couple of edits a month would help to circumvent the problem of admins hogging their admin privileges when they are inactive. Dreamy Jazz 🎷 ^{talk to me | my contributions} 16:52, 25 November 2018 (UTC)
• Oppose. I have been an admin for over ten years. I am an active editor; I'm on pretty much every day. My understanding always was that admin privileges are intended to be used sparingly. I try to warn vandals rather than block and I don't waste effort blocking IP accounts that appear to come from public terminals in schools. Usually after being warned and reverted a couple of times vandals just go away. I try to help settle disputes where I can and that often makes me an "involved editor" so I sometimes have to rely on other admins if my efforts fail and blocks are needed. A few times when I did use my bit, it just made a bad situation worse. Nonetheless, there are times when I do use it and often having to wait for permission to get it back would allow damage to persist too long. I would not object to tighter authentication requirements for admins, perhaps re-authentication when the bit is used after an absence from editing (rather than relying on "keep me logged in"). But I don't think admins who are active on the project should be incentivized to use their privileges any more than they deem necessary.-- agr ( talk) 17:35, 25 November 2018 (UTC)
• Support If you do not use your administrator rights you do not need them but i oppose the requirement of 2FA as not all admins have phones and the way Wikipedia uses 2FA has issues Abote2 ( talk) 22:20, 25 November 2018 (UTC)
• Oppose. Wikipedia is becoming more punitive. People should always be notified when things are planned that affect them. There seems to be a trend toward trying to make people do things in a particular way or in a particular time frame recently. I contend that this attitude is driving users away. As a volunteer organisation we should be doing everything we can to retain and encourage users. Also rushing to change policy in reaction to a specific situation is never a good idea. Morgan Leigh | Talk 22:28, 25 November 2018 (UTC)
• Oppose. This is security theater. We are going to have compromised accounts and do need processes in place to prevent it, mitigate the damage, and allow recovery. The reduction in the size of the attack surface that would result from this policy change is simply not significant, and the consequences for editor engagement over time are considerable. The Uninvited Co., Inc. 00:22, 26 November 2018 (UTC)
• Conditional support on the condition that any former sysop who hasn't fallen short of the 3-year lengthy inactivity rule can regain the sysop flag anytime via WP:BN. In other words, I would support this proposal for as long as it only removes the technical permission of an admin who still edits occasionally but hasn't used any admin privileges, but retains the policy permission for those admins to regain their technical permission whenever they need it back. Also strong oppose requiring the current implementation of WMF 2FA per diversity issues raised by Risker et al and the technical issues raised on phab:T172079. Deryck C. 16:05, 26 November 2018 (UTC)
• Strong Oppose -- This won't solve any problems. Just see the recent temporary desysop of Killiondude. The account was compromised and the real editor had edited the day before. I would much rather see an actual activity requirement of say 25 logged actions per year (edits; blocks; user right changes; whatever). -- Dolotta ( talk) 16:47, 26 November 2018 (UTC)
• ( edit conflict) Support the bit can be returned on request. There shouldn't be mandatory 2FA for all admins, as it might be too difficult for some. Besides, how would one get 2FA before, since if I recall users without advanced rights (admin, CheckUser, oversight, etc.) can't use 2FA. ^Semi _Hypercube ✎ 16:51, 26 November 2018 (UTC)
• Support -- as long as it is easy enough to reinstate in extenuating cases (which seems to be the case here) no harm no foul.--Esprit15d • talk • contribs 00:02, 27 November 2018 (UTC)
• Strong Oppose, ah, here we go yet again down the slippery slope. I've always seen admin activity requirements as unhelpful for a number of reasons, including but not limited to the effect that this would have to de-diversify the admin population, effectively shutting down the possibility of adminship to those who may not have reliable secure internet for long periods--military deployment, missionary work, humanitarian aid, and the like. Not even requiring notification adds an addition slap in the face for those who frankly have donated a lot of their free time to the project already. Andrew Lenahan - Starblind 18:54, 27 November 2018 (UTC)
• Oppose – Right spirit; wrong proposal. Normal edits should count toward admin activity, since by editing actively, admins, who are of course all virtuous and knowledgeable, can show by example so admin actions don't have to be performed. Inform people that the bit is about to be taken away, especially because real admin activity, such as DYK actions, aren't even being counted. However, I'd make the activity requirement higher, like average one action a day, not a year. How does someone who does less vandal fighting in a year than I'm apt to do in a day get to keep their key to the executive broom closet? Dhtwiki ( talk) 07:47, 28 November 2018 (UTC)
• Support but I agree with Dhtwiki that this should just be about keeping your account active in general, not about making demonstrably 'admin' actions. To me, the point of de-sysopping inactive admin accounts is to maintain security of an account that has no one on the other end of it. If an administrator is active in any way, that means he or she is logging in regularly, (hopefully) changing the password and keeping it secure, etc. If we want to de-sysop an otherwise active sysop for lack of admin-specific activity, that's fine, but we should be doing so for all advanced permissions and separately from this proposal. CThomas³ ( talk) 19:53, 28 November 2018 (UTC)
• Oppose both requiring logged admin actions and the removal of the notice requirement. While I understand the concerns, I don't think that they outweigh the problems of tracking unlogged admin actions (I think of closing AfD's as "No Consensus" as a good example) and the discourtesy of finding your account deadminned unexpectedly even when you have been making regular if infrequent contributions to the encyclopedia. I probably came close to a year without logged actions when I was an admin, and I would have hated to have lost the bit without even a warning. Eluchil404 ( talk) 23:08, 28 November 2018 (UTC)
• Support the first part. I don't, however, see a defensible rationale to deleting the notice/contact provisions.  —  SMcCandlish ☏ ¢ 😼  12:44, 1 December 2018 (UTC)
• Oppose. I see the problem, but this is too extreme. I might support some more complex formula such as (<n admin actions in last 12 months, and <n admin actions in last 2 years), but I'd prefer to see some human discretion applied, partly to avoid setting a target for the hat collectors. Any numerical threshold risks encouraging hat-collecting admins to make un-needed admin actions simply to game a threshold.

Most of my admin actions involve editing protected pages, and AIUI those are not logged as admin actions. Unless they are included in the total counted, the numbers will be misleading.

And I strongly oppose mandatory 2FA. I am sure that I am not the only admin who is a smartphone refusenik (a phone which needs to have a "phone" button pressed before it can be used as a phone is a portable identity crisis which I don't need in my pocket; plus my fossil-phone is way cheaper, more robust and has a 1-month-on-standby battery life) .. and 2FA basically relies on having a smartphone. Instead, I change my password frequently using my own obscure formula, and I would support an enforced requirement for non-2FA admins to change password every 3 or 6 months or so. -- BrownHairedGirl (talk) • ( contribs) 04:01, 3 December 2018 (UTC)

• Support. All users are responsible for securing their accounts. Accounts with sensitive privileges should be subject to additional security measures to reduce disruption to Wikipedia. Disabling inactive privileges and requiring two-factor authentication are measures that are widely implemented in companies with strong computer security policies. As the fifth-most-popular website in the world, Wikipedia is more important than many of these companies, and should tighten its security to prevent embarrassing breaches like the ones from last month. —  Newslinger  talk 04:57, 3 December 2018 (UTC)

• @ Newslinger: Wikipedia is not a company, and cannot be run like one. Its editors and admins are a much more diverse set, and your comparison seems to assume that en.wp editors have the same sort of access to resources as an employee of a major tech company.

Its editors are unpaid and receive no equipment from Wikipedia. They may not own a computer, and do their editing on someone else's machine or on some sort of public computer (e.g. library, school, university, work, housemate, family).

So any requirement which presumes ownership of particular equipment merely reinforces the already-massive systemic bias in en.wp's admin base, and erects a further barrier to editors on lower incomes, editors from remote areas or developing nations, editors with disabilities etc. -- BrownHairedGirl (talk) • ( contribs) 07:40, 3 December 2018 (UTC)

​ Two-factor authentication doesn't require any additional equipment beyond what is needed to edit articles on Wikipedia. If an editor can run a web browser or a Wikipedia app on their own device, then the editor can also run a free authenticator app ( list) or password manager ( list) on their device (regardless of whether it's a desktop, laptop, or smartphone). For editors without their own devices, there are web-based password managers (such as KeeWeb) that also provide two-factor authentication at no charge. —  Newslinger  talk 08:54, 3 December 2018 (UTC)

• @ Newslinger: there may indeed be workarounds for the tech-savvy. But those workarounds increase the technical burdens on admins who are mostly chosen for their editorial judgement and understanding of policy, rather than for technical skills.

You really don't seem to get my point that Wikipedia is not a company and its editors and admins are not employees. This is a wholly different sort of organization, and these attempts to import corporate processes don't recognize that crucial distinction. I know some truly wonderful editors who would make brilliant admins, but who are so non-techie that they only ever use the visual editor. They would run a million miles from the complexity of 2FA, but they precisely the sort of people whose social and editorial skills are much needed in the admin corps. I would love to see more of them becoming admins; the role should not be the sole preserve of tech-heads. -- BrownHairedGirl (talk) • ( contribs) 09:07, 3 December 2018 (UTC)

​I made the "company" comparison to show that Wikipedia's security practices are weaker than those of less important organizations. This was not an assertion that Wikipedia is like a company, or that its editors and admins are like employees. In my opinion, two-factor authentication is much easier to learn than wikitext, and is a reasonable requirement for sensitive privileges on a very important website. —  Newslinger  talk 09:34, 3 December 2018 (UTC)

Newslinger, comparisons with a company have led you down a path where you are applying inappropriate measures of reasonableness, and looking at the perceived importance of the organisation rather than the extent of potential harm and the impact on users. Please do not underestimate the extent of the barrier which is placed in the way of many very productive editors and admins by technical measures which a tech-savvy person like yourself would find trivial.

As a voluntary group, en.wp editors include very many people who would never be remotely acceptable to the personnel depts of any corporate. Their contributions are valuable, and their needs are very different to those of a corporate employee.

Most of the potential for damage has been removed by https://phabricator.wikimedia.org/T150826, which prevents a blocked admin unblocking themself. A hijacked admin account can now be securely blocked until the issue is resolved.

And do remember that this is "the encyclopedia which anyone can edit". Our security is social rather than technical. -- BrownHairedGirl (talk) • ( contribs) 11:29, 3 December 2018 (UTC)

• Oppose. Tweaking the activity requirements every time someones account with bad password gets compromised is just security theater. Also strong oppose requiring the immature WMF 2FA per diversity and editor retention issues raised by Risker, Andrew Lenahan and others, and the technical issues raised on phab:T172079. jni  ^(delete) _{...just not interested} 06:27, 3 December 2018 (UTC)
• Oppose, forcing admins to have logged actions and not telling them they have forgotten to do so doesn't strike me as helpful. It is trivial to fulfil the logging requirement (delete and undelete your sandbox) so this is useless as a measure of activity. And anyway, what jni says. — Kusma ( t· c) 11:18, 3 December 2018 (UTC)
• Oppose, hard cases make bad law. Stifle ( talk) 15:20, 3 December 2018 (UTC)
• Oppose - per Risker, pretty much. Also, I'll join the list of people opposed to compulsory 2FA, at least while using it requires people to retain one-time keys indefinitely. The Land ( talk) 15:40, 3 December 2018 (UTC)

• Strong support. Best proposed modification to this policy in quite some time. As usual the opposition is a storm in a teacup around something that will pose no threat to the project's operations. It will on the other hand shut down the yearly charade performed by people who have no good reason to continue calling themselves administrators.  — Scott • talk 15:48, 3 December 2018 (UTC)
• Strongly oppose: this doesn't reduce risk, per Risker, so it's pointless. It's also counterproductive. We need more experienced admins, not fewer, and admins are usefully so even without logged actions. Much of what we do as admins isn't logged. Jonathunder ( talk) 02:24, 4 December 2018 (UTC)
• Oppose A solution for a nonexistent problem. We need more admins not fewer. Λυδ α cιτγ 09:57, 4 December 2018 (UTC)

• @ Jonathunder: Believe it or not I wrote that before noticing your comment. Great minds, eh? ;-P Λυδ α cιτγ 09:58, 4 December 2018 (UTC)

• Oppose I don't use my admin abilities that often, much less frequently than I edit. And I am one of the most experienced admins on Wikipedia. Does reviewing deleted edits count as an administrative action? Other people have made excellent points in opposition about the broader implications. -- The Cunctator ( talk) 15:15, 4 December 2018 (UTC)
• Mildly oppose the 12 month limit. Deactivation of inactive accounts must be done somehow (and BTW, we need to think about reusing user names, if we do not already; if WP last for decades I hope someone will be the next Nabla :-). But legislating in a hurry is bad (as Risker said), the rule is too simplistic, and no warnings feels like punishing. Strongly Oppose 2FA, when it came up I gave it a look, it was almost impossibly convoluted, wikipedia is less and less a wiki (as in easy to edit) let's not make it something only for the special ones. Note I am an almost inactive admin, I edit once in a while, I have made none or almost none administrative action in the last ya«ear or so, mostly because I went back to college so I *am* busy. I have been considering temporary resigning, because I do not want to fool the statistics; and I would not mind a *friendly* reminder in that sense, but this is not it at all. - Nabla ( talk) 23:02, 4 December 2018 (UTC)
• Support, but strongly Oppose mandatory 2FA. Kudpung กุดผึ้ง ( talk) 02:15, 5 December 2018 (UTC)
• Support As an editor and former admin who has returned to the project very recently, I was initially surprised to find that administrative work had become a "very big deal," mostly on the basis of these identity hacks. So, I have to support any resolution which would seemingly improve the security of editors in general and admin accounts particularly. In that many of the identity hacks have been perpetrated by inactive admin accounts, I should thank @xeno in this space, for his diligence in deactivating my account when he did. I should also note that as far as editing the project, I don't miss the extra tools very much at all. I think See Recent Changes would be useful to me as I could be doing more cleanup editing. Most of you are doing excellent work, and it is appreciated by me. Hamster Sandwich ( talk) 04:22, 5 December 2018 (UTC)
• Oppose If they aren’t active enough, they wouldn’t even know they got a admin revoke. No-go. We should get a better criterion to keep adminship, for example 100 admin actions and 500 edits in a year, etc.. Oshawott 12 ==()== Talk to me! 12:44, 6 December 2018 (UTC)
• Oppose Ugh, no just no. Whispering^{( t)} 15:48, 6 December 2018 (UTC)
• Oppose. Airbornemihir ( talk) 10:44, 7 December 2018 (UTC)

  The case of Revolving Bugbear is somewhat pertinent here. I'm really not fond of the way they were singled out for attention, and specifically asked to "at a minimum" justify their retention of the administrative toolset. I think that's an undue "minimum" ask to make. I also disagree with the judgement call to remove their permissions after their ambivalent-at-best statement at the bureaucrats' noticeboard. This proposal is trying to codify the same kind of judgement call on an automatic (or semi-automatic, since it's done by individual bureaucrats, not software) basis, hence I am opposed. I note the amount of tedious work made for admins, and the harm done to the 'paedia, when an admin account is compromised. I would suggest searching for another solution to solve that problem. Airbornemihir ( talk) 19:39, 7 December 2018 (UTC)

• Oppose per Risker. -- Tavix ^{( talk)} 19:17, 13 December 2018 (UTC)
• Oppose as written. I am not against this in principle, but the proposal is problematic in a number of ways. Not notifying is unforgivable. If a notification prompts a user to come back and do some admin work, that is a good thing, not a problem. Also, as others have pointed out, there are a number of tasks that require admin rights but do not get logged. DYK has already been mentioned, OTRS volunteers are another example. They need to read deleted pages. Spinning Spark 09:56, 15 December 2018 (UTC)

• Oppose- for this to be a good idea, the accounts of admins who edit but no longer use their tools would need to be easier to compromise than completely inactive admins and admins who do use their tools. So far, there has been no evidence presented that this is the case. Reyk _YO! 10:07, 15 December 2018 (UTC)
• Support - seems reasonable.-- Staberinde ( talk) 11:30, 15 December 2018 (UTC)
• Support - Cleanly reduces the security risk in admin accounts, while retaining anyone who is adminning. Tazerdadog ( talk) 19:38, 17 December 2018 (UTC)
• Strong Oppose - I strongly oppose both the changes to the Administrator inactivty requirements and the forced 2FA authentication. There are many admins and editors who do not edit Wikipedia regularly, but that doesn't mean that they are less valuable than those who edit here regularly. Any action and decision that concerns any editor or administrator should always be informed to the concerned person on their talk page. Removing the administrator rights or any other userrights of an established editor without any valid reason and information is completely unacceptable. TheGeneralUser ( talk) 23:36, 18 December 2018 (UTC)
• Support - Inactive admins, and indeed editors in general who are inactive in the article space, are a problem. If you're going to go through RFA then you've got to commit to working on this project. My only proviso is that there should be an easy mechanism for re-instatement, and that people absent for parental leave/illness should be taken into consideration. FOARP ( talk) 07:59, 22 December 2018 (UTC)
• Oppose The current proposal failed to consider unlogged admin actions. Viewing deleted pages is certainly one that falls within the scope of unlogged action. Correcting Main Page errors is another (yes, you can check edits under WP namespace which is considered "logged", but this isn't the first place people go check your log activity and if you make plenty of WP namespace edits, it's almost impossible to notice it). OhanaUnited ^{Talk page} 01:16, 24 December 2018 (UTC)
• Strong Oppose Wrong problem. The problem is trying to retain the admins we're losing, not make us lose more admins. -- Dweller ( talk) Become old fashioned! 19:26, 27 December 2018 (UTC)
• Oppose mainly per Dweller - this is not helping security and has the potential to lose wikipedia more editors. Cas Liber ( talk · contribs) 19:57, 27 December 2018 (UTC)
• Support: inactive admins are not admins, per se. It's not that hard to perform one logged admin action per year. -- K.e.coffman ( talk) 20:05, 30 December 2018 (UTC)
• Support per User:Johnuniq Smallbones_{( smalltalk)} 23:53, 30 December 2018 (UTC)
• Support Wiki is always changing. Inactive admins will not be up to date. Ronhjones   ^(Talk) 23:48, 1 January 2019 (UTC)
• Support per User:Johnuniq. Pharaoh of the Wizards ( talk) 12:39, 4 January 2019 (UTC)
• Support. I've always thought telling them beforehand that the bit is about to be removed seemed unproductive and defeating the purpose. This proposal makes sense to me. But I do think that User:Hut 8.5's comments need to be taken into consideration. -- œ ^™ 06:41, 6 January 2019 (UTC)
• Support per User:Johnuniq. -- B dash ( talk) 10:30, 10 January 2019 (UTC)

Questions about admin actions that are not logged as such

• Comment - In theory, I support tighter guidelines on whether or not an admin is really making use of their tools. However, as pointed out above by Jo-Jo Eumerus and others, there are certain actions that require admin access, but are not logged as admin actions. DYK is a prime example, as some editors have become admins specifically for helping out on that project. There are some admins I see using their tools at DYK, and don't run across them elsewhere, but are vital to assisting that project. Devise a tool that logs ALL admin usage of tools, and I might be more willing to support this. — Maile ( talk) 19:50, 22 November 2018 (UTC)

  DYK has come up a couple times. I'm not so familiar, but what do admins do at DYK that requires admin access but isn't logged? IMO it should be logged, or it should not require admin rights. Ivanvector ( ^Talk/ _Edits) 19:58, 22 November 2018 (UTC)

  They use editprotected. -- Izno ( talk) 20:01, 22 November 2018 (UTC)

  Ah I see. Surely we could (should?) log edits to protected pages? Maybe that's a separate discussion too. Ivanvector ( ^Talk/ _Edits) 20:10, 22 November 2018 (UTC)

  @ Ivanvector: technically they are already logged, just not in any manner that is easy to find. Obviously "group" edits (like MediaWiki:, .json files, etc) are easy to filter, but the other ones are not. I wonder if this is a red herring though (i.e. how many admins are completely inactive in all logged actions but still routinely use editprotected?) — xaosflux ^Talk 20:43, 22 November 2018 (UTC)

  Does it require admin tools to create and maintain bots and scripts? That's also a key part of DYK. — Maile ( talk) 20:37, 22 November 2018 (UTC)

  I don't believe so, I think anyone can operate a bot if it's approved, unless it's a bot with admin rights. Scripts might require interface admin now, I'm not sure. Ivanvector ( ^Talk/ _Edits) 21:08, 22 November 2018 (UTC)

The last 10 humans, and the operator of the last bot, to edit Template:Did you know, made their most recent logged admin action this long ago:

As you can see, Gatoclass is the only one who would lose their adminship with this proposal. Thryduulf ( talk) 22:51, 22 November 2018 (UTC)

Thryduulf of the ones you list above, Shubinator is unique in that his bots keep the process running. He's the only one who would know what admin actions he's taken that don't show on his normal logs - but I think DYK would be up a creek without him behind the scenes. You don't list Wugapodes, and his logs look pretty active, but he operates WugBot that is also essential to the DYK processes. The others are directly involved in the edit protected areas of DYK that directly affect what appears on the Main Page. — Maile ( talk) 01:34, 23 November 2018 (UTC)

I believe I wasn't listed because I'm not an admin, only pending changes and (recently) new page reviewer. WugBot doesn't have editprotected rights and doesn't need them as the approved page isn't under full protection, just the Queue for the mainpage. Wugapodes [t^hɑk] [ˈkan.ˌʧɹɪbz] 02:47, 23 November 2018 (UTC)

• Regarding the questions about logging, while it's not as easy of a log, we could make an edit filter such as ((action = edit) & (page_restrictions_edit = sysop)) to "log" protected edits such that they could be "counted" by any inactivity bots (which really is how we would look for inactives in practice). — xaosflux ^Talk 05:28, 23 November 2018 (UTC)
• Example of logging the use of protected edits. — xaosflux ^Talk 12:55, 23 November 2018 (UTC)

Although my understanding of logging administrator actions is dim, I believe I could have been desysopped for one year of miscalculated inactivity from Sept. 15, 2014 to Sept. 25, 2015, and also Sept. 26, 2012 to Apr. 22, 2014. That's logged actions only. Realistically, I'm far from inactive; I proofread everything on the Main Page, not just Did You Know. So it isn't just Gatoclass. But if you'd rather fix typos without me, my business could use more attention. Art LaPella ( talk) 06:03, 23 November 2018 (UTC)

• This is another example of a fully protected page which requires editing by administrators on a regular basis.-- Ymblanter ( talk) 07:55, 23 November 2018 (UTC)

• The fact that just in the last 10 admins to have processed a DYK already 1 of them would be removed means that clearly DYK is a necessary tagging. In preference, any edit of a protected page should also count. Nosebagbear ( talk) 13:46, 23 November 2018 (UTC)
• So, if I'm understanding correctly, the only admin action we've identified so far as definitely an admin action and definitely not logged is edits to protected pages, yes? Let's set up a log for that. I don't think anyone here yet has said we shouldn't, and lots of us have said we should. Ivanvector ( ^Talk/ _Edits) 14:50, 23 November 2018 (UTC)

  @ Ivanvector: I'm working on one ( Special:AbuseFilter/942) - there is another admin action that isn't logged at all: viewing deleted versions. Note, those 'actions' are not currently counted toward activity. — xaosflux ^Talk 14:54, 23 November 2018 (UTC)

I saw that filter you're working on, it looks good so far. As for viewdelete, are there really that many admins that only look at deleted pages and do nothing else? Ivanvector ( ^Talk/ _Edits) 15:02, 23 November 2018 (UTC)

Indeed, while you can have admins look just to answer individual's questions (why was it deleted etc), usually I'd expect it to be associated with one of:DELREV, CSD, Salting/Unsalting, copyvio, block discussions. Nosebagbear ( talk) 15:21, 23 November 2018 (UTC)

I mean I'm sure there are cases where you just look at a deleted page and then do nothing else. But does anyone only look at deleted pages, but never do anything with them, or any other logged actions? That seems unlikely to me, but then again I was wrong about DYK and editprotected, so as it turns out I don't have all the answers. Ivanvector ( ^Talk/ _Edits) 18:25, 23 November 2018 (UTC)

Personally, I feel viewing a deleted page to be something that an administrator is authorized to do, but not an administrative action in itself. Using the knowledge gleaned from this to weigh in on a discussion would be an administrative action. However I don't see any way to log this automatically. isaacl ( talk) 23:17, 23 November 2018 (UTC)

• Also noting that I oppose counting non-logged admin actions that is next to impossible to track after the fact. Seriously, it really isn’t that difficult to do one completely non-controversial logged action a year, and handwringing over something that is easily reversed and can be easily fixed for a year isn’t justified, especially given the extra work that would be required. I would support keeping the one year notice, though. TonyBallioni ( talk) 22:35, 23 November 2018 (UTC)
• It does appea that DYK is the single exception where an admin is actually doing useful admin work without logging any actions. As demonstrated above thsi would impact only one single admin's rights. That doesn't seem sufficient cause for not doing this, we can just IAR for that one admin. Beeblebrox ( talk) 02:09, 24 November 2018 (UTC)

  At least two admins. And probably Shubinator. And it's the complete Main Page, not just DYK. Art LaPella ( talk) 03:49, 24 November 2018 (UTC)

  I actually provided another example in this very thread.-- Ymblanter ( talk) 08:24, 24 November 2018 (UTC)

• I think that one of the most valuable things that administrators do is say no....say no to blocking someone, say no to protecting a page, say no to deleting... And yes, there's lots of work happening in places like Arbcom enforcement and even admin noticeboards by admins who don't need to take logged admin actions in order for them to be effective as administrators. If someone is actually around and doing things, it really doesn't matter whether or not they're doing logged admin actions. I will make a proposal above. Risker ( talk) 02:17, 24 November 2018 (UTC)
  • But do you think it is reasonable for an administrator to say no to literally everything? All they have to do is say yes one time (or however many actions the limit is determined to be). If we have a sysop that is saying no to every request, I would find it very hard to believe it is not a WP:POINT situation, and they should not be an admin anyway. Natureium ( talk) 13:46, 24 November 2018 (UTC)
• As I understand it, there is currently no logging of the use of admin accounts to view deleted edits. This is one of my most common uses of the tools, for example in checking out a candidate or potential candidate at RFA. I'm actually a little uncomfortable about the idea of an admin account quietly lurking and occasionally being used to view deleted edits, but we have in the past had a very active nominator who made little or no use of the tools apart from viewing deleted edits. So I would welcome some sort of log that at least recorded when an admin had last looked at deleted edits, provided it didn't log what specifically they viewed. Ϣere SpielChequers 13:32, 24 November 2018 (UTC)

  I've created a AF log for "protected edits" that can be seen here: Special:AbuseFilter/942 - a 'viewdelete' log would require software changes so its a bit hard. For example @ WereSpielChequers: can you point out any specific admins who have gone a year with no protected edits, no logged actions - that you think are still using viewdelete usefully? — xaosflux ^Talk 15:52, 24 November 2018 (UTC)

  Great, thanks.-- Ymblanter ( talk) 16:09, 24 November 2018 (UTC)

  @Xaosflux Thanks. As I said we had an active nominator in the past who as I remember it had not otherwise used the tools for some time. I don't know if there is such an admin at present. But there are plenty of occasions where view deleted is useful, if you are about to recreate a previously deleted page sometimes the only way to know that the previous A7 deletion was of a "14 year old professional skateboarder" and unlikely to be the same person as the diplomat or academic of the same name who you are writing about. Ϣere SpielChequers 16:42, 24 November 2018 (UTC)

  Will this filter be automatically disabled if it matches more than 5% of edits, or does this wiki have a different setting for $wgAbuseFilterEmergencyDisableThreshold? I don't see anything about this on Wikipedia:Edit filter. I've run into that problem a lot on other wikis where I've worked with abuse filters, and I'm guessing the restriction was put in place to prevent situations like this incident that occurred here. Or is this not a concern because there are so many edits to English Wikipedia that it would never reach 5%? ♫ ekips39 (talk)❀ 22:23, 24 November 2018 (UTC)

  @ Ekips39: the sheer amount of other edits should keep this down, it is currently running at about a 0.02% hit rate against edits. — xaosflux ^Talk 04:20, 25 November 2018 (UTC)

  @ Xaosflux: Is there any way to make meaningful statistics out of the filter log - which pages are most edited, and who are the administrators with the largest numbers of edits (and possibly smth else)? -- Ymblanter ( talk) 17:12, 6 December 2018 (UTC)

  @ Ymblanter: these can be queried programmatically live ( example - click SUBMIT) , from the database, or off of dumps, so someone could make a bot generated report (request at Wikipedia talk:Database reports). — xaosflux ^Talk 18:00, 6 December 2018 (UTC)

  @ Xaosflux: Thanks, I will try to follow up when I have a bot more time.-- Ymblanter ( talk) 19:02, 6 December 2018 (UTC)

• Creatimg new logs is overkill - all Admins can just accept the occasional CSD which IS logged. Legacypac ( talk) 22:41, 24 November 2018 (UTC)

• I don't think this is just DYK. Another group that has come up in previous proposals of this sort is the OTRS volunteers. A necessary part of their work is to read deleted articles when they are queried. Reading a page, even a deleted page, is not logged anywhere, so I don't see how a bot could make an exception here, unless it automatically excepted all OTRS volunteers. There are bound to be other edge cases that haven't come to light, which is why I think silently desysopping without notification is not acceptable. Not only must there be notification, but there needs to be a formal channel to appeal so the desysop can be cancelled before it takes effect. Spinning Spark 10:09, 15 December 2018 (UTC)
• There's a few more examples of "somewhat logged" but not in the exact way. Correcting Main Page errors is "logged" but in the forms of edits and if you edit a lot of WP namespace, it can easily escape detecting the logged action. Same for requiring an admin to close a deletion discussion. OhanaUnited ^{Talk page} 01:10, 25 December 2018 (UTC)
• The issues which I can come up with of using one's admin bit without an obvious way of finding it:
  1. Unblock review - while some of these require either an unblock action or a block change to disable talk page access, most don't; any which don't have no obvious log to find.
  2. Viewing deleted edits, apparently an issue for OTRS users.
  3. Editing protected pages. While the edit is clearly logged in the page history, seeing several days, weeks or months later that the page was protected at the time isn't self-evident.
  4. Moving a page to an existing title other than reversing a redirect with no history - while the deletion itself is logged, so is a redirect-reversal move done by a non-admin.

עוד מישהו Od Mishehu 13:32, 9 January 2019 (UTC)

Alternative ideas

This has been a very good discussion and I'm very impressed with the diversity of comments, thanks everyone. I've definitely learned some things and had my assumptions challenged. Based on the key points raised up to this point I have an alternative suggestion:

• An account is considered inactive when it has no presence on the website at all (no edits, no logged actions) for 91 days.
• When an account is flagged inactive, we force a password reset and send the accountholder instructions to change their password, by email (if the account has email enabled) and with a notice on their user talk page. (The current password reset instructions are here)
• If/when the user wants to resume using their account, with all its previous permissions, all they have to do is reset their password.
• Since the password must be reset before the account can be used again, no permissions are changed (unless the account becomes subject to the lengthy inactivity policy)
• I believe requesting a password reset counts as a logged action; it's present in the Checkuser log at least but of course that's not public, and it rotates after 90 days anyway. At any rate, the accountholder resetting their password should reset the 91 day clock, and if someone wants to string along keeping their admin access by resetting their password every three months, that's not really a security issue.
• 91 days is just an illustrative number I pulled out of my ass, it could be any reasonable number.
• Two admin accounts (at least) and several others with other advanced permissions have been compromised while we've been talking about this.

I think that this catches all of the concerns raised about admins who are active but don't log actions, about automatic removal of permissions, and about accounts being hacked due to old reused password hacks on other websites. Some issues are:

• Accounts that don't have email enabled or accountholders who lose access to the email they provided on sign-up could be locked out. I think these situations can be handled by contacting Arbcom but I've never had to so I don't really know.
• Accounts that are active will never be required to change their password, but that's already the case.
• There is nothing in this alternative (nor in the original) that requires strong passwords or extra authentication factors, other than having an email address.

Any thoughts on something like this? Ivanvector ( ^Talk/ _Edits) 15:52, 24 November 2018 (UTC)

The WMF security team is actively working to introduce technical measures that will prevent future attacks along the same vector that compromised the most recent two admin accounts. I'd argue that they are the experts and should be the ones making the call in this area. Us debating the pros and cons of each potential security measure not only exposes all of their cons in public, making it easier for an attacker to work around, but also is far less effective because most of us aren't experts in the area.

My suggestions is to limit discussion on this topic to what would generally promote account security, without getting into detailed technical solutions. De-flagging inactive accounts is good because it reduces the attack surface. I feel like any of these discussions are more about punishing the barely-active admins who dare to have other things going on in their lives than editing Wikipedia rather than actually being about security best practices, but I guess it's at least being considered. -- Ajraddatz ( talk) 16:59, 24 November 2018 (UTC)

I disagree pretty much with everything you've said. "The office is working on it" is no substitute for community discussion on local policies, especially since the security team does things in a silo, slowly, with no accountability to the actual users of this project. There is no sinister ulterior motive here to punish anybody, or drive anyone away, or ... anything, I apparently can't anticipate the bullshit schemes people are going to insist on reading into this. It's about security best practices, and responding to an actual and ongoing security threat in any way that the local community is capable, because the security team has not. You seem to think that this hacker is an idiot and isn't already aware of all the things being discussed here, like these are brand new ideas that haven't already been implemented by security-conscious websites pretty much everywhere in the world for years now. The website haveibeenpwned.com has been tracking security breaches for five years of exactly the sort of info that's very likely being used to hack idle accounts here, and the best innovation we've had from the WMF in that time is a beta 2FA implementation that's problematic for many users, if the WMF allows them to use it at all. We don't need more vague promises that the under-resourced WMF has " top men working on it", we need a response now. Anything less is grossly irresponsible. Ivanvector ( ^Talk/ _Edits) 18:47, 24 November 2018 (UTC)

I think the hacker is aware of discussions like this, or at least able to find them. I'll email you about some of the other points. -- Ajraddatz ( talk) 18:55, 24 November 2018 (UTC)

Just to note that how we are having admin-account vandalism has been publicized (even though it would take just a bit of reading on en.wiki to figure out what's been happening). This basically means that the security hole due to the ability hack into admin accounts could get worse. -- Masem ( t) 01:48, 25 November 2018 (UTC)

Would it help to send an e-mail to all administrators alerting them on the incident and asking to evaluate the strength of their password and to change it if necessary? Those who do not have e-mail enabled can get a talk page message.-- Ymblanter ( talk) 10:41, 25 November 2018 (UTC)

• A simple alternative While not having much of the finesse of Ivanvector's latest proposal in this section, using recent-ish changes it would (I believe) be trivially simple to assign the bit as a temporary (365 day) permission, with an expiry on the anniversary of the admin's initial grant of the bit. Perhaps a 24hr pause before re-granting to anybody who had absent for a significant period. Simple to do, no new infrastructure needed, no advertising of inactive accounts - I think this meets the requirements. Cabayi ( talk) 14:28, 27 November 2018 (UTC)

Separate section for comments that are only about 2FA

• Regarding 2FA, I don't remember (or just don't now, really) if anyone has access to stats on which accounts have it turned on or not. If we do, and we're not yet comfortable requiring it to be turned on for admins, maybe we can do something like enforce periodic password resets for admins that don't opt in. That's not part of this proposal, I'm just throwing out ideas. (I have 2FA turned on, ftr) Ivanvector ( ^Talk/ _Edits) 19:27, 22 November 2018 (UTC)

  Well, I have a password which can not be broken. I do not want to turn on TFA because I (almost) do not use a cell phone. I am not sure why WMF thinks they are more clever than I, and I am already unhappy with 2FA requirement for interface admins - I will possibly have to resign my interface admin rights, but if RFA is required for all admins, I am not sure what I am going to decide. If you want to lose admins with zero benefit, this is probably the way to go.-- Ymblanter ( talk) 19:33, 22 November 2018 (UTC)

• @ Ivanvector: Way back in Feb '17, " 203 out of the 1274 admins on English Wikipedia [had] enabled two-factor auth". Other tasks exist asking for a similar thing - TNT ^💖 19:37, 22 November 2018 (UTC)

Neither a data plan nor a smart phone is required. All 2FA processing is done off-line, using a seed number and the current time to generate a key. Apps such as Google Authenticator and FreeOTP can run on any Android or iOS device without a data connection (and FreeOTP can be downloaded on your PC from here and sideloaded onto an Android device if WiFi isn't available for installation). If you do not have a smartphone/pda/media player that runs Android or iOS, you can get PC-based programs to generate the codes ( WinAuth and Authy seem to be the most popular, and there are more options available for Linux-based computers such as gauth and oathtool). -- Ahecht ( TALK
PAGE) 19:46, 26 November 2018 (UTC)

This is a good discussion, but I've broken it out from the main proposal so as not to distract too much. I like our 2FA implementation because I always have my phone with me, and because my phone is also my authentication device for my office email, but of course it's not perfect for everyone. We could fall back on the "email you a code" type 2FA that some other sites use ( Steam is one, and I hate it, my email server is slow) if it were possible to choose different authentication methods. Again, just a thought. Ivanvector ( ^Talk/ _Edits) 19:55, 22 November 2018 (UTC)

In light of the number of reset requests I am wondering if the current 2FA methods run too high a risk of getting locked out of one's account. Besides, not all people are tech savvy enough to work with one device 2FA or have more than one device available at any time. Jo-Jo Eumerus ( talk, contributions) 20:36, 22 November 2018 (UTC)

• You would have lost me as an admin if you'd required TFA. Not only is it far beyond my level of technical comfort, and makes it all too easy to get locked out, I'm not going to spend $400 plus data plan for a smartphone for Wikipedia or anybody else. Massive imposition for little gain to the project in terms of security. Yngvadottir ( talk) 22:55, 22 November 2018 (UTC)
• Ditto. I act as an admin as a favour to Wikipedia, sysop status isn't a favour Wikipedia does to me. I have no intention of committing to permanently owning—and having permanent access to—an expensive piece of technology which requires a permanent and expensive subscription. purely because Wikipedia is having one of its periodic bouts of security paranoia, and if that means someone else has to clean out CAT:EX instead of me I believe I can live with the loss. ‑  Iridescent 23:01, 22 November 2018 (UTC)

@ Iridescent: I can understand where you, Ymblanter, and Yngvadottir are coming from in relation to having 2FA be a requirement, but it's not as much of a commitment as the ghastly WP:2FA leads on. The most popular applications for this process are for mobile (namely Google Authenticator and Authy), but PC-based applications exist too. There are a few listed here, and there are others, like WinAuth for Windows. If you use Google Chrome, Authy has an available plugin. Unfortunately, I was unable to find any for Mac (that were not already listed) or Firefox. I didn't bother looking for Safari ones, and Brave, along with Opera I believe, primarily use Chrome extensions. Internet Explorer/ EDGE are both a mess, so I'd recommend to anyone using those to swap browsers anyway. If losing the codes is what your worry about, scratch codes are generated when you enable 2FA. Email these to yourself and you'll never lose access to your account, even if you lose or change device. Anarchyte ( talk | work) 23:33, 22 November 2018 (UTC)

gauth is available for Firefox. I should also note that Google Authenticator does not require a "perminant and expensive subscription", and it doesn't even require any internet acess beyond the initial installation (which can be done via WiFi). Used android devices are readily available cheaply ($10-$20) without a data plan if you don't need the latest and greatest flagship model. -- Ahecht ( TALK
PAGE) 19:53, 26 November 2018 (UTC)

• Just noting as I did above that there are multiple functionaries that do not have 2FA, and for a variety of reasons, I would not even want to force this on CheckUsers or Oversighters, including but not limited to the fact that the security paranoia that Iridescent describes is very real and there are some plain insane ideas on functionary account security out there and there is a part of me that fears making this a requirement would be a slippery slope to some really dumb measures that would make a lot of people quit (yes, slippery slope is a bad argument, but WMF projects tend to make technical changes all at once if they ever happen.)
  That was all about functionaries, who I think should have a higher level of account security than admins because of the ability to access personal data. If we currently don't require CU/OS to do it, and I don't think we should, we certainly shouldn't extend the requirement to admins without those tools. TonyBallioni ( talk) 01:36, 23 November 2018 (UTC)

  @ TonyBallioni: it is being discussed see phab:T197160. — xaosflux ^Talk 05:55, 23 November 2018 (UTC)

  Xaosflux, thanks. -revi pointed me to the CU one and one for changing user rights. My general view on this is what I said in the CU one: there is no world where it should be more difficult to run a CU than it was for me to wire money to buy a house, which is an accurate description of some of the suggestions that have been made re: 2FA and the CU tool. TonyBallioni ( talk) 06:17, 23 November 2018 (UTC)

• Wikipedia, and the entire Wikimedia movement, is committed to creating and maintaining a diverse community. That means including people who have limited access to technology (in some cases, even limited access to software), people who do not have a lot of money, people who live in countries where it is not legal to own certain types of technology (or could result in significant state surveillance if owned). This is not an abstract concept - I personally know administrators who live well below the poverty line, some of whom don't even own their own computers; others who can't afford to maintain a second piece of technology like a mobile phone; and still others who live in countries where using 2FA would probably result in their being incarcerated. Frankly, there's almost nothing that an admin account can do that will result in any real level of off-wiki scrutiny. Admin accounts that go rogue are pretty easily globally locked. I also completely and fully endorse everything that Iridescent said. This is security theatre and is completely out of proportion to the problem it's trying to solve. Risker ( talk) 04:51, 23 November 2018 (UTC)
  • Risker, not to mention that the most recent confirmed account compromises involving stewards (which *actually* could have had real life implications given the potential access to CU data on multiple projects) could not have been stopped by 2FA. TonyBallioni ( talk) 04:59, 23 November 2018 (UTC)
    • @ TonyBallioni: Would you be able to link me to these compromises involving stewards? I haven't been keeping up, but I don't entirely understand how 2FA couldn't have stopped it (unless their computers were infected, in which case nothing would have prevented it as they were already logged in). Anarchyte ( talk | work) 05:05, 23 November 2018 (UTC)

I can confirm it has happened, but currently there is no on-wiki postmortem. — regards, Revi 05:10, 23 November 2018 (UTC)

And I can confirm that even those stew with 2FA were compromised. I can't talk about the details per BEANS (and other security constraints). — regards, Revi 05:12, 23 November 2018 (UTC) [ Clarification: The stew with 2FA compromised is NOT related to this incident. I'm talking about the past incident. — regards, Revi 03:42, 25 November 2018 (UTC) ]

Thank you for the (albeit restricted) clarification, -revi, though I can't help but think that something else must have also played a role in the compromising of the accounts. Having two separate devices prevents malware from getting to both the username and password, and the ever-generating 2FA code (I could give you my current 2FA code and it would be useless by the time you read this message). This is especially true given the major authenticators do not use accounts and are wiped if they're reinstalled (and, in the case of iPhones at least, are not saved to iCloud or iTunes when backed up to a computer). If someone's LastPass or 1Password are hacked and their 2FA system is compromised, then its not the fault of the system but rather the poor security employed by the account holder. This is all under the assumption that all the issues were at the user's end and that someone didn't just walk up to a computer with a logged in account (in which case ∞FA wouldn't have prevented it). Anarchyte ( talk | work) 05:30, 23 November 2018 (UTC)

Requiring someone to own two separate pieces of expensive technology in order to be an administrator on a Wikipedia project is completely inappropriate and extremely exclusionary to anyone who doesn't have the ability to pay out thousands of dollars a year. We choose administrators because they are sensible, not because of their bank accounts or geographic location. Americans in particular seem to find it shocking that in a lot of countries, the phone that costs $200 in the US costs six months' wages, and that in other countries the typical internet connection costs 10-15 times as much as the average American family will pay. I pay about 3 times as much as the average American for considerably less access. Risker ( talk) 05:55, 23 November 2018 (UTC)

@ Risker: I noted this in a response above, but you do not need to devices to enable 2FA. Sure, it's more "secure" to use more than one, but downloading WinAuth for Windows (which has an extra layer of protection through a password and locking the data to your Windows user account) or Authy for Chrome accomplishes the exact same task. The only thing preventing someone from installing those pieces of software (or a Mac equivalent on this list) would be if the device has restrictions preventing non-vetted exes from running or if they are locked to a clean web browser.

I tested WinAuth while writing this response and it was very intuitive. See here for an image gallery explaining the process. Anarchyte ( talk | work) 06:45, 23 November 2018 (UTC)

Good on you for trying to find a solution, Anarchyte; I do appreciate the effort. But again, it is entirely dependent on the user owning certain technology. It does not address the person who edits from school or public libraries, for example; as I've worked my way through the Wikimedia world, I've learned that what we take for granted here in the "Western" world is not the norm in the rest of the world. The WMF has already identified increased diversity as a critical goal in the coming decade, and so solutions need to be developed that not only accommodate but are actually focused on ensuring that people who don't own computers/smartphones can actively participate in our projects, and there are quite a few projects of languages from the poorest countries in the world. I'd like to encourage you to think more about how we can ensure that those projects can have their own admins - because we all have seen that once rules like this get applied to enwiki, they go through all of the Wikimedia projects unless there's an extremely concerted effort by a very big player (like German Wikipedia, for example). Risker ( talk) 09:13, 23 November 2018 (UTC)

@ Risker: Hmm, yeah. I didn't consider the precedent this would set. 2FA is a very loose term and doesn't have to be auto-generating 30-second-life-span codes accessed through secondary devices. An idea Ivanvector mentioned above, that I've also had experience with, is having codes emailed to a user. These will last longer (a few hours), have basically the same effect (prevent people from entering an account through a username/password breach), but will be slightly less secure due to the account's standing being entirely dependent on one outlet (the email address). Another idea that Steam and a few other applications use, like Facebook and Google, is remembering devices rather than browsers. I have literally no idea how this could be implemented (especially as it's a website rather than an app), but the gist is to have it so the user sets a device as being "okay" and then when the user logs in from these devices, it won't ask for verification. This prevents easy log-ins from hackers with one's username and password but doesn't hinder the account holder (usually). Anarchyte ( talk | work) 10:03, 23 November 2018 (UTC)

"Remembering devices rather than browsers" is a total non-starter. As Risker says, it's easy for the core "relatively wealthy middle-aged people in Five Eyes countries" editor base to lose sight of the fact that sizeable chunks of the editor base don't operate on the same "home computer and a cellphone" basis. We have people who edit from work where they might be using a different terminal each day; people who edit from public libraries where it will obviously be inappropriate to install software; people who live in places China and Belarus where using any kind of secure system will make the authorities assume you're up to something and start prying into your private life; a fairly large contingent of serving military who edit Wikipedia as a hobby in their downtime on base and for whom installing unauthorized software on the computers or suspicious activity on their personal devices would likely get them locked up… If there were a genuine, serious issue to address then it would conceivably be justifiable to de facto ban particular chunks of the editor base from becoming admins, but since nobody's demonstrated any problem more significant than "a handful of admins used the same password for Wikipedia and Twitter and failed to change it when Twitter's password database leaked", that would seem to be a sledgehammer/nut situation. ‑  Iridescent 10:31, 23 November 2018 (UTC)

You're right, Iridescent. The email idea was the one I was going with to resolve the issue of not having a designated device and the "remembering devices rather than browsers" was to try to alleviate the concerns of those who think 2FA is too much of a hassle. Apologies if this wasn't clear. Anarchyte ( talk | work) 10:48, 23 November 2018 (UTC)

( edit conflict) Without saying too much, this really wasn't a 2FA problem. I'm not anti-2FA (I use it myself and recommend anyone with advanced permissions where it is practical do so), but I also recognize there are valid reasons not to have it. Some financial. Some personal. Some just ease of using the technology, which can be an issue. It isn't a silver bullet and while it does provide an added layer of security, the fervor with which it is promoted when a high-profile compromise happens can miss the point that it is simply one tool for protecting your account, and that people should take reasonable steps to have a secure account as fits their particular situation. Mine allows for 2FA. I know of several functionaries where their situation doesn't allow for it. They all take reasonable precautions with their accounts, which is really all we can ask of them. What I would really like to see is a WMF password audit, as that would likely be a much more high yield activity, but I suspect that isn't happening anytime soon. TonyBallioni ( talk) 06:53, 23 November 2018 (UTC)

Mandating 2FA would impose additional hassle on hundreds of administrators. And what problem would it solve? We had a compromised admin account. It made 8 or 10 admin actions, it was globally locked, the actions they had made were reverted, done. Pragmatically in terms of "person hours" it is much quicker to resolve such issues in the way we currently resolve them then it would be to make every administrator jump through 2FA hoops, all the additional hassle for stewards resetting passwords when people bodge up their login or lose their phone, and so on. Mandating 2FA would be an overreaction to a very infrequent problem. Fish+ Karate 09:21, 23 November 2018 (UTC)

• For what it's worth, I'm also opposed to mandatory 2FA for any level of account. I use it myself because it works for me, but I absolutely understand that there are technological and financial challenges with WMF's implementation (and/or in general) for many users. Strong passwords and good password hygiene are also important, but we can't really mandate those things, we can only advise and recommend. Just to add info to the pile, I use a password manager along with 2FA wherever it's available, I use passwords generated by the manager or xkpasswd for things I really need to remember, and I've moved money out of accounts with banks that still use a six digit number as an internet password. Ivanvector ( ^Talk/ _Edits) 14:59, 23 November 2018 (UTC)
• Given the problems that come with it (both inherent and any via a flawed system) then I wouldn't say anyone short of a steward or IntAdmin should need it. In its ideal form I am neutral to obligating it for admins - but certainly not at this time. Nosebagbear ( talk) 15:23, 23 November 2018 (UTC)
• With the second administrator being compromised today (3rd one this year) it is time to make having 2FA be a mandatory component for all new Admins (passing a RFA), all Admins requesting simple Resysoping, and all advanced privilege (Requiring identification to Foundation) holders. We've seen what a compromised admin and oversighter can do. Fundamentally the 2FA is one of the least intrusive ways to make the attack surface more difficult to succeed at. Hasteur ( talk) 22:39, 23 November 2018 (UTC)
  • Hi, Hasteur. The WMF does not require identification of advanced permission holders, and has not required this for several years. There are many reasons for this; amongst the more important is that they do not have a method of securely storing the identification information, and the simple fact that they will not be able to verify that the identification documents sent to them truly belong the the person behind the account. Instead we are all required to read and sign a confidentiality agreement with our logged-in user accounts. Risker ( talk) 04:28, 25 November 2018 (UTC)
• I oppose mandatory 2FA: a proper password is plenty secure, while with 2FA it's too easy to lock yourself out of your account. Imposing 2FA would also effectively mean requiring admins to maintain committed identities and so on to convince sysadmins to unlock their accounts. BethNaught ( talk) 10:14, 24 November 2018 (UTC)
• As others have pointed out 2FA is fine for a real world organisation where employees work several hours at a time and are identified to HR and company IT/Security. It isn't such a good fit for a volunteer organisation like this, and can actually militate against editor retention, specifically editors returning after multi year holidays - not a common issue for corporate IT. If password protection for admins needs to be improved, then set some software in place to force a password reset on any admin account with a password shorter than 16 digits. Ϣere SpielChequers 13:05, 24 November 2018 (UTC)
• I won't be using 2FA. 3 reasons: (1) I have a unique, long, password (as does the email account I use only for Wikipedia) (2) Having seen the results of an organisation I did some consultancy work for when they introduced 2FA ... yeah, you can probably guess the rest... (3) You seen the mobile reception round here? Black Kite (talk) 23:32, 24 November 2018 (UTC)

  @ Black Kite: just to clarify, our 2FA solution is not "on line", that is no connectivity is required between the authentication device and anything else, not for enrollment and not for use. — xaosflux ^Talk 20:26, 25 November 2018 (UTC)

• Heh, I accidentally locked myself out of my own account this morning. I logged out to use one of my alts, forgetting that I had just started a system update on my phone and couldn't access my authenticator app. I could've looked up my scratch codes to get back in but I didn't have anything urgent to do so I just waited for the update to finish. I'm just saying 1) it happens to people who think they know what they're doing, and 2) you can recover your account if you do something dumb like this, but it's a hassle (it's supposed to be a hassle). Ivanvector ( ^Talk/ _Edits) 17:14, 25 November 2018 (UTC)
• Just a comment on forced periodic password resets (not entirely just about 2FA, but I can't see a better section). It's been largely debunked as a means to security, and it often just makes people change to passwords that are easier to remember (and therefore easier to hack). One place I worked briefly enforced monthly changes to passwords, and a significant number of people started using "January", "February" etc. That can be prevented by insisting on strong passwords, but with strong passwords you avoid any need for periodic changes anyway. If someone is victim to a brute force attack, all a periodic change really does is eliminate the passwords already tried and force the hacker to start again. So with a good strong password, a forced 3-month reset might reduce the mean time to hacking from, maybe, 50 million years to 49,999,999 years and 9 months. Strong passwords are the way to maintain security (and by that I don't mean nonsense like 8 characters including 1 digit and one upper case letter, I mean proper strong passwords), coupled with login attempt throttling, and maybe a good 2FA system where something extra might be needed (but 2FA isn't the real answer). Boing! said Zebedee ( talk) 12:47, 3 December 2018 (UTC)

  I've just used a "Check the security of my password" site to check a few passwords. I did *not* check any of my real passwords on the possibility that it's a fake password-grabbing site! (though I used one at Russia's Kaspersky Lab, so that should be fine ;-) The results were interesting, with estimated computer-based cracking times...

  "January" - 4 seconds

  "Jan" - 7 microseconds

  "January1947" - 8 minutes

  "TomatoTrinket" (two random words) - 21 days

  "toMatOtRINket" (same two words with random caps) - 20 years

  "_QPZ#~pGww:6Q,7\" (from a random password generator) - 10,000+ centuries

  A password of similar length and format to my Wikipedia password - 8,763 centuries

  Some sites will offer a false sense of security, so be wary of any results. One, for example, reckoned "January1947" would take 41 years to crack, and I presume that's just doing a brute-force random-character attempt rather than trying any "Hmm, I wonder if it's when they were born?" connection of months and years. But I think it makes my point about strong passwords being the crux of it. Boing! said Zebedee ( talk) 13:09, 3 December 2018 (UTC)

  I changed my password the other day as it seemed like good advice. My old password would have taken a pitiful 2,000 years to brute force. Lame! My new one, a far safer 552 quadrillion years. I think the bigger risk these days isn't your password being brute forced, it's your password being used on multiple sites. I had this issue once when LinkedIn dropped a bollock and gave away everyone's passwords. It wasn't the same password I used here, that's always been unique, but I did have to change passwords on about 40 different sites and learned a valuable lesson. NEVER REUSE PASSWORDS ANYWHERE EVER. Fish+ Karate 13:46, 3 December 2018 (UTC)

  Definitely, yes, never reuse passwords between sites. Boing! said Zebedee ( talk) 14:36, 3 December 2018 (UTC)

  Looking at my results again, I suspect the site I used got "_QPZ#~pGww:6Q,7\" wrong - it's only 16 chars from the printable ASCII set, and "10,000+ centuries" seems way too optimistic. Boing! said Zebedee ( talk) 14:38, 3 December 2018 (UTC)

• I support all the comments above by @ Fish and karate, Iridiscent, and Risker. This is a security panic, which is entirely un-needed now that admins no longer have the power to unblock themselves. A hijacked admin account be be spotted, blocked, and the damage cleaned up quickly.

As others noted above, 2FA also imposes burdens on admins which they may not be able to meet for a whole variety of reasons: financial, logistical, state security policy, neurological diversity, etc etc. It is sad to see how some editors simply assume that because their life circumstances make 2FA easy for them, the same applies to everyone else.

If there was en.wp decided to take just one step to further reduce our already appallingly low levels of diversity, this would be near the top of the list. Luckily, en.wp's policies are aimed at increasing diversity. -- BrownHairedGirl (talk) • ( contribs) 13:37, 3 December 2018 (UTC)

• An observation: it appears that what's written in this month's administrators' newsletter is the WMF's entire response to these hacks: they're not doing anything at all about vulnerable accounts, they're just passing the buck to users to secure their own accounts. Of course, their message will not get to inactive admins, so be vigilant for more hacks. Ivanvector ( ^Talk/ _Edits) 14:19, 3 December 2018 (UTC)
  • That's a very poor observation. It's standard practice among security professionals to not publicly discuss the details of every mitigation strategy, to make it a bit harder for the attacker to adapt. Anomie ⚔ 13:09, 4 December 2018 (UTC)
• Agree with Boing! said Zebedee - my last job had us changing password every month - a lot ended up using a "core" password and added a 2 digit number to the end of it (and then writing the 2 digit number on the back of the PC...) FWIW, I do have 2FA installed, only because of c:Commons:Administrators'_noticeboard/Archive_69#URGENT:_CHANGE_PW_/_ENABLE_Two-factor_authentication, since I'm an admin on commons as well, and there was no great oppose to not implementing it (but there are only about 250 of us). In the end it cost me nothing to implement - I wrote a short python script User:Ronhjones/2FA for my PC - I just run it when I need a code (and it gives me my adminbot code as well). Ronhjones   ^(Talk) 18:45, 3 December 2018 (UTC)

  Ah yes, I remember now - I just added "Jan", "Feb", etc to my existing password (which was already quite strong). Previous ones couldn't be reused, but they gave up on the scheme long before 12 months and the need for a new root. And while we're doing password anecdotes, I had to try breaking into a colleague's account once (as he'd left some broken jobs clogging up the overnight batch queue - I'm showing my age). His username was just his first name, so the first thing I tried was his surname, and I was in - and his surname, appropriately, was "Hack". Boing! said Zebedee ( talk) 19:01, 3 December 2018 (UTC)

Mandatory 2FA considered harmful

Allowing 2FA is fine, as long as the scheme uses meets the requirements of [ https://pages.nist.gov/800-63-3/sp800-63b.html#sec5 ]. Encouraging 2FA is also fine. Requiring' 2FA is a really, really bad idea. It is security theater, and in general is less secure than simply using a long, easy-to-remember-but difficult-to guess passphrase.

https://www.makeuseof.com/tag/two-factor-authentication-sms-apps/

https://www.wired.com/story/two-factor-authentication-apps-authy-google-authenticator/

https://thestack.com/security/2016/04/08/anywhere-computing-makes-2fa-insecure-on-ios-and-android/

-- Guy Macon ( talk) 07:38, 23 November 2018 (UTC)

I'll note that the articles you provided counter your point of passphrases being good enough. "And remember, any 2FA is better than no 2FA. Yes, it might take you an extra 10 seconds to log into certain apps, but it’s better than sacrificing your security." "the few minutes it takes to set up an authenticator app are more than worth the benefit". Here are three articles that support the use of 2FA:

• What Is Two-Factor Authentication, And Why You Should Use It - MakeUseOf
• What Is Two-Factor Authentication and Why You Should Use It - Motherboard
• Two-factor authentication: How and why to use it - CNet

Calling it a security theatre is subjective, and the article from The Stack is contradicted as "anywhere computing" relates to syncing information across devices, and these applications don't do that (at least Google Authenticator and WinAuth). I can understand possible situations in which someone cannot enable 2FA, but I see little reason to not if you can. So what if it takes someone an extra two minutes to log in? I'd much rather have to do that every so often than wake up to find my account compromised because Wikipedia or the connected email was hacked. And that goes for most sites that offer 2FA (I might not use a site's 2FA if I rarely use the site, but if someone's an admin+, it's hopefully safe to assume they're somewhat dedicated). Anarchyte ( talk | work) 08:23, 23 November 2018 (UTC)

Just to comment - it is pretty clearly security theatre to suggest that the way to prevent compromise of admin accounts is to apply 2FA, when the last two reported admin or higher account compromises would not have been prevented even if the compromised accounts had had 2FA. It is also pretty clearly security theatre to suggest that removing admin permissions at a lower threshold will prevent situations where the accounts need to be blocked/locked/desysopped, when the overwhelming majority of admin accounts that have been desysopped would have met just about any activity criterion the community could reasonably come up with. So yeah. Security theatre. Risker ( talk) 09:24, 23 November 2018 (UTC)

We hear about the successful attacks to compromise accounts, but never the unsuccessful ones. While I'm doubtful it has occurred, we would never be able to know if someone managed to guess the password to an admin's account who had 2FA enabled. There's a ping if they get it wrong a certain amount of time, but nothing for getting 66% of the way there (33% each for username, password, and 2FA). If that's an example of a security theatre, so is requiring CVVs for credit cards. It's simply a fail-safe to prevent people from giving away all their information. You could take a photo of the front of your card and no one could purchase anything online. I could give you my password and you wouldn't be able to access my account. I'm not saying 2FA is the be-all-end-all; just like CVVs aren't. If they were, we would never have a breached 2FA-enabled account and we would never have to worry about people using someone else's credit card. It's an extra layer of protection. Anarchyte ( talk | work) 09:47, 23 November 2018 (UTC)

That's a false analogy. Compromise of a credit card causes the real loss of real money. Compromise of a Wikipedia account—even an admin account—causes someone to be a mild nuisance for a couple of minutes before having their contributions rolled back. Even assuming every editor had access to the technological means to use 2FA, an additional 10 seconds per day adds up when you multiply it by 1000-ish admins (not to mention the opportunity cost of "I've just noticed a problem, but I won't bother logging in to fix it because it would mean going downstairs, finding the phone and turning it on"). There are theoretical ways a compromised account could do genuine damage and force the WMF to perform a database rollback, but they've never once happened. The risk from a genuine holder of advanced permissions leaking data or systematically disrupting is orders of magnitude greater than the risk from a potentially compromised account, and even installing iris recognition on the computers of every admin would have zero impact on admins becoming disgruntled, drunk, involved in personal vendettas, or just bored. ‑  Iridescent 10:46, 23 November 2018 (UTC)

Fraud is usually intercepted by the bank and the account gets locked with the money spent being charged back, when possible. With this said, the analogy wasn't to give perspective to the connotations, rather that fail-safes like 2FA are all around us. I agree with your other points, though. Anarchyte ( talk | work) 11:01, 23 November 2018 (UTC)

Going off of Iri’s point, this just happened, and while the account claims compromise, that is unlikely and in every likelihood we had a CheckUser on another WMF project (who at one point had access to en.wiki data that was stored on CU-wiki) was operating a goodhand-badhand sock situation on multiple wikis. Compromise is a concern obviously, but the chance of admin socking or a functionary going rogue is actually a much greater risk in my view. Again, I am not anti-2FA, but I do think we need to have a realistic view of actual risks. TonyBallioni ( talk) 22:45, 23 November 2018 (UTC)

Sure, but did we ever had breach of an account with say 20+ character password which was not reused on any other sites? Ideally if the recovery mail is also protected by a 20+ character password which has never been used elsewhere?-- Ymblanter ( talk) 11:17, 23 November 2018 (UTC)

People haven't been going around revealing their compromised passwords. Length isn't the defining factor, complexity is. See this 8-10GB file of hacked passwords and you'll see that while less common, accounts with randomised passwords still get hacked. These sites may not be Wikipedia ( some are actually bigger: 150 million Adobe and 165 million LinkedIn accounts, for instance) but we'd be ignorant to assume we can't be hacked. Anarchyte ( talk | work) 12:05, 23 November 2018 (UTC)

I kinda get the feeling that if we make 2FA mandatory, that will just become the next target. If we don't make it mandatory but everyone on the site still used 2FA (except me because my password would take "4.06 hundred million trillion centuries" to crack and isn't listed in any dumps) then passwords remain the more visible option (even if they only get my password well after homo sapiens is no longer a thing). If someone is not going to use 2FA, they need to check for their passwords on Have I Been Pwned? and if there's any chance it might have leaked, change it to something that will outlast the site. Ian.thomson ( talk) 17:00, 25 November 2018 (UTC)

If credential stuffing is what's going on here, a better idea is to use a unique password on Wikipedia which you do not use and have not ever used on any other website. If it's a brute force attack then Macon's Principle is a good guide. And then there's session hijacking, and for that I don't know, but I do know if you log out of Wikipedia it logs out all of your sessions on all devices. Ivanvector ( ^Talk/ _Edits) 17:10, 25 November 2018 (UTC)

In my experience, if you log out once you are logged out of all sessions at all devices. (Though I must confess I was this years in a situation on my ipad when I was logged on the English Wikipedia but not on Commons or Wikidata).-- Ymblanter ( talk) 17:41, 25 November 2018 (UTC)

Correct. Logging out of any Wikimedia site logs you out of all of them. Additionally, changing your password logs you out of all sessions besides the one used to change the password. In light of the recent events, I decided to changed mine (and my 2FA secret key) to verify this. I recommend other people do the same even if you think your password will take aeons to crack. Anarchyte ( talk | work) 04:35, 26 November 2018 (UTC)

Ian.thomson, How do you know https://www.grc.com/haystack.htm wasn't hacked at the time and you haven't given hackers your password by checking it there? ;-) Boing! said Zebedee ( talk) 13:31, 3 December 2018 (UTC)

Because the calculation takes place client side, not server side (you can load the page, disconnect from the net, and still check passwords). Also, I checked different scrambled forms of my password (substitution cipher on all the characters and then either swapped the front half and back half or then put the characters in alphabetical order). Ian.thomson ( talk) 19:14, 3 December 2018 (UTC)

@ Guy Macon: I disagree that enforcing 2FA for everyone would be security theatre. One of the nice things about 2FA is it is very hard for a person to screw up. During the enrolment phase, users are given a barcode of the master secret to scan into their phone (or other device). The barcode is generated by the website, which means it is complex enough, and unique to the website. Compare this to a password - the user is expected to come up with a unique complex password that they never reuse. It is much easier for a user to screw this up. In fact the path of least resistance is to simply use an easy to remember word for every website. Hence the problem of people using the same password on multiple websites. Now sure, people could also post their 2FA barcode to twitter or something like that, but that would be really odd behaviour and the user has to go out of their way to compromise the security of 2FA in that manner. In my opinion, user security is much like any other thing in the world. You have a certain small number of people who are really good at it, a large group of people who are in the middle, and a small number who are really terrible. Education can of course shift the mean to the right, however when you have a group of 1200 people, I am doubtful you can ever educate people enough so that there isn't a single person using a poor (or shared) password. Attackers of course don't care if 1199 admins have good passwords, they only attack the 1 person who has a poor password. This is why mandatory 2FA would be an effective security solution - people have very little freedom to do it poorly, so if everyone is forced to use it, then everyone has a base level of security, and the attacker cannot simply choose the weak leak. (I should of course clarify that 2FA is not a panacea. It won't prevent phising attacks. It won't stop your younger sibling from going on to your computer and deleting the main page while you are in the bathroom. It will however stop one of the most common ways website accounts on the internet are compromised: People using the same password on a different website that got hacked. I also want to acknowledge that 2FA is not without its costs. I'm only arguing that it is a measure with actual benefits and definitely not security theatre. Like any security measure it has costs and benefits; it has things it protects against and things it does not). BWolff (WMF) ( talk)

I oppose forcing people not to use 2FA and I oppose forcing people to use 2FA. I support giving them a choice (possibly with stern warnings). What you described above (mandatory 2FA) would prevent me from logging into Wikipedia when I work in China. I bring along the stupidest possible flip-phone (can't run any programs, no camera), and I run the TAILS operating system on a cheap computer I buy locally and leave behind. I have no way to scan in a barcode while in China, and any barcode that is in my luggage must be assumed to be copied by my opponent (industrial espionage by a Chinese toy manufacturer who has full cooperation from the Chinese government). Again, the user should be given a choice.

If you *really* want to stop Wikipedia users from using the same password on a different website that got hacked, give the user a pronounceable four or five character string and tell him he must start his 12-or-more character password with it. Not that I recommend such a scheme, but it would accomplish your stated goal. -- Guy Macon ( talk) 00:44, 5 December 2018 (UTC)

All I am saying here is that mandatory 2FA has real security benefits in many realistic threat scenarios (including the 3 most recent admin compromises), and thus is categorically not Security theatre. Security theatre is usually a term used to talk about security initiatives that are very visible but have essentially no benefits against realistic attackers. Whether or not the security benefits of mandatory 2FA outweighs the costs in the context of enwikipedia admins, is a different question, and one that requires very different arguments than establishing whether or not it would be pure theatre. (As an aside though, I'll note that its surprising the types of devices that support 2FA. For example totp-me works on many basic flip phones). BWolff (WMF) ( talk) 03:49, 5 December 2018 (UTC)

Macon's Principle

(If the following is too long for you, just read https://xkcd.com/936/ and https://xkcd.com/538/ ) and skip to the next section.)

Two factor authentication has its uses, but it is no substitute for a passphrase that is easy to remember and hard for a high-speed offline passphrase-guessing program to guess. I have decided to call this "Macon's principle" so that I don't have to type "choose a passphrase that is easy to remember and hard for a high-speed offline passphrase-guessing program to guess" again and again.

If you follow Macon's principle, 2FA or any other form of add-on security is not needed.

As explained at Kerckhoffs's principle and Security through obscurity, we are not to rely on anything other than having a sufficiently long (See Brute-force attack) passphrase without any easy-for-a-computer-to-guess patterns in it.

We are to assume that the attacker knows every byte of information on the WMF servers (and in fact the attacker may actually be someone who knows every byte of information on the WMF servers -- If a nation-state offered a key WMF employee millions of dollars if he complied and made a credible threat to torture and kill his family if he didn't, there is a 99%+ chance that they would end up knowing every byte of information on the WMF servers.)

We are not to assume that the attacker cannot perform a high-speed offline passphrase-guessing attack.

We are not to assume anything about the amount of cleverness and computing power that the attacker has, other than arguments based upon basic math and physics (The attacker cannot spend more time than the age of the universe, he cannot have more memory available than the size of the universe will hold -- that sort of thing).

The WMF does not store your passphrase anywhere. When you enter it it a cryptographic hash is performed and the result compared with a stored hash. This means that an attacker who knows every byte of information on the WMF servers can perform a high-speed offline passphrase-guessing attack, but cannot simply look up your passphrase and use it to log on.

So according to Kerckhoffs's principle, you should choose a passphrase that is easy to remember and hard for a high-speed offline passphrase-guessing program to guess. The passphrase should only exist in your mind; never write it down, never say it out loud, never store it on any computer or online system.

Bad ways to follow Macon's principle

• Passwords instead of passphrases (single words instead of strings of words with spaces between them).
• Random gibberish.
• Short passwords or passphrases. 8 is awful, 16 is marginal, 24 is pretty good, 32 is so good that there is no real point going longer.
• Character substitutions (Example: ch4r4ct3r sub5t|tut10ns)

Good ways to follow Macon's principle

• Use a standard English sentence with proper grammar, spelling, and punctuation.
• Make it longer than 32 characters and have it contain at least three (four is better) longish words plus whatever short words, capitalization and punctuation are needed to make it grammatically correct.
• Make sure that sentence has never been entered anywhere on your hard drive (including deleted files) or on the internet. "My Hovercraft Is Full of Eels" is bad because a dictionary that contains every phrase used in Monty Python's Flying Circus would find it. [3]
• Make it meaningful, easy to remember, and something that generates a strong mental image.
• Make it meaningful to you, but unguessable by others (don't use your favorite team, first kiss, mother's maiden name, etc.)

An example of a good passphrase that follow Macon's principle would be:

 Sherwood painted his Subaru pink so that it would blend in with his flamingos.

(This assumes that you actually know someone named Sherwood and that he owns a non-pink Subaru. To make it easy to visualize and remember, you should use a name/car from among your acquaintances)

That's 78 characters that nobody in the history of the earth ever put together in that order until I wrote it. Typos really stand out (Sherwood paibted his Subaru pink so that it would blend in with his flamingos.) and are easy to correct. The sun will burn out long before the fastest possible passphrase-guessing program completes 0.01% of its search. And yet it would be far easier to remember than the far easier (for a computer) to guess HZn?m+jW1 would be.

(Side note: When I say "Use a standard English sentence with proper grammar, spelling, and punctuation." I mean use what you consider to be a standard English sentence with proper grammar, spelling, and punctuation. If, you, overuse, commas, and, kant, spel, that's fine as long as you do it the same way every time. And if you are better at Spanish, use what you consider to be a standard Spanish sentence with proper grammar, spelling, and punctuation. Just write your passphrase in whatever way you normally write. If you are handicapped in such a way that you cannot type the same thing every time, sorry, but you are hosed on Wikipedia or on any other system that requires a username or password. My advice also doesn't work if you are in a coma or are Amish and not allowed to use a computer. None of this applies to Wikipedia users.)

I could walk you through the math, but Steve Gibson has already done it for us. See [ https://www.grc.com/haystack.htm ]. Just type in your current password/passphrase and it will tell you how well it does against a brute force password guessing attack. The calculation is done locally, using JavaScript, so the password doesn't leave your computer.

If you don't want to risk typing in your password, try these 8-character test passwords (Generated from an atomic decay true random number generator):

• HZn?m+jW (chosen from the 95 ASCII printable characters (01...89abc...xyzABC...XYZ `~!@#$%^&*()-_=+[{]}\|;:'",<.>/?) - 7.66 hours to crack.
• PhBixXL4 (chosen from the 62 ASCII a-z/ABC-Z/0-9 characters (01...89abc...xyzABC...XYZ) - 36.99 minutes to crack.
• qza7nm3g (chosen from the 36 ASCII a-z/0-9 characters (0123456789abcdefghijklmnopqrstuvwxyz) - 29.02 seconds to crack.
• pgupwmxn (chosen from the 26 ASCII a-z characters (abcdefghijklmnopqrstuvwxyz) - 2.17 seconds to crack.
• 54606559 (chosen from 10 ASCII 0-9 characters (0123456789) 0.00111 seconds to crack.

Try it with 12 characters, 16 characters, etc.

Now try "Sherwood painted his Subaru pink so that it would blend in with his flamingos." on the GRC calculator. The time to crack goes from minutes or seconds to ten billion trillion trillion trillion trillion trillion trillion trillion trillion trillion trillion centuries.

I should also mention dictionary attacks. My collection of cracking dictionaries is getting big enough that I will likely have to buy a bigger drive to hold them soon. (No, I am not a malicious hacker. Some companies hire me to evaluate their security. Or at least that's the story I am telling now... :) ) The good news is that if you use two words in a dictionary separated by a space, the time for an exhaustive search is squared, and with three it is cubed. The example I made up above "Sherwood painted his Subaru pink so that it would blend in with his flamingos." has 14 dictionary words. Even if the dictionary was really tiny (say, 1000 words), that's 10^42 guesses. And such a tiny dictionary is unlikely to contain "Sherwood" (with the capitalization) "Subaru", or "flamingos." (with the trailing period). So "Sherwood painted his Subaru pink so that it would blend in with his flamingos." is also ridiculously resistant to dictionary attacks.

-- Guy Macon ( talk) 17:21, 23 November 2018 (UTC)

How about also randomizing the sapces? E.g, S herwoodp aintedh isS ubarup inks ot hati tw ouldb lendi nw ithh isflamingos? —— SerialNumber 54129 14:29, 24 November 2018 (UTC)

That would take exactly as long to brute-force crack, and how are you going to remember where you randomized the spaces? Ivanvector ( ^Talk/ _Edits) 15:53, 24 November 2018 (UTC)

Exactly so. Randomizing the spaces violates one of my suggestions (Use a standard English sentence with proper grammar, spelling, and punctuation) and adds zero benefit. More importantly, Serial Number 54129 should have entered his suggested passphrase into [ https://www.grc.com/haystack.htm ] and compared it with "Sherwood painted his Subaru pink so that it would blend in with his flamingos." That would have told him the relative strength of the two passphrases against a brute force password guessing attack. -- Guy Macon ( talk) 22:13, 24 November 2018 (UTC)

Hm, just mentioning here that a very short phrase -- the names of my best friend's weirdly named cats -- shows as taking at minimum 38 centuries to crack. Which would actually protect me in every case except someone who knew me well enough to make that educated guess. Thanks for this info, Guy Macon. -- valereee ( talk) 12:06, 25 November 2018 (UTC)

Sherwood painted his Subaru pink so that it would blend in with his flamingos.

Trouble is, after a period of non-use, this could easily be misremembered as containing any one of

• so that it would match
• so that it blended in with
• so that it would go with
• so it would blend in with

et cetera. And that's just one part of the sentence: Sherwood might have sprayed his Subaru, or had it painted, or....

The XKCD suggestion is better, I think: just four words.

The next problem is that the Wikimedia websites require just one among perhaps fifty passwords that are required of me (many of them used only once a year or so). If I'm not to store them on my hard drive, then how should I remember them? -- Hoary ( talk) 12:18, 25 November 2018 (UTC)

Remember, you should create a mental image Sherwood painting his Subaru pink and of it blending in with his flamingos. If the language first comes to your mind is "matching his flamingos" use that language, and create a mental image of him putting them next to each other and seeing if they match.

Last "problem" first: Use a password manager that keeps all of your passwords in an encrypted container so you only have to remember the one macon's-principle-compliant passphrase that accesses the rest. This also soles the "seldom used" problem; you end up using it a couple of times every day.

For most people Passsafe [4] is a good choice for a password manager. I often do engineering work inside of a factory in China in an industry (toys) where the threat of industrial espionage is high, so for me every webpage gets a password like this: weO'5QvWH6oeRjKQ;EU/I@alk#<0CJ5a/&FmHrV>/}O5]p{+Km}gJ~^e9'5=tznK and all of the passwords are stored as text files on a thumb drive that is encrypted using Veracrypt using multiple algorithms. Most people don't need that level of protection.

Next, it is not true that the XKCD advice is better than mine. That comic was written as an example showing that "correct horse battery staple" is easier for a human to remember and harder for a computer to guess than the "Tr0ub4or&3" alternative -- which it clearly is. Note that he assumes 1000 guesses per second, which violates Kerckhoffs's principle. We are not to assume that the attacker cannot perform a high-speed offline passphrase-guessing attack. We are not to assume anything about the amount of cleverness and computing power that the attacker has, other than arguments based upon basic math and physics (The attacker cannot spend more time than the age of the universe, he cannot have more memory available than the size of the universe will hold -- that sort of thing).

If you apply Macon's principle to the XKCD comic, you get the following very strong passphrase:

      The horse said "That's a battery staple". I replied, "Correct!"

Randall Munroe knows all of this, but I challenge anyone to fit all of the details needed to apply Macon's principle into a six-panel comic.

Here is a discussion of the math behind that particular comic:

http://security.stackexchange.com/a/6096/33

Or, as Bruce Schneier wrote: "This is why the oft-cited XKCD scheme for generating passwords [...] is no longer good advice. The password crackers are on to this trick." [5] -- Guy Macon ( talk) 16:18, 25 November 2018 (UTC)

Bruce is wrong about this, as several of the comments on his page point out. As long as the words in the passphrase are chosen uniformly randomly from a list or dictionary, the entropy of the passphrase can be computed from the number of words in the passphrase, N and the number of words in the list, L, as entropy = N*log2(L). If the entropy is high enough, cracking is not going to work. It doesn't matter that the cracker knows how your are doing this. One way to get uniformly random words is using dice. See Diceware. (COI alert, I'm the developer.) Your method, by contrast, requires people to exercise judgement on what is random enough, and there is plenty of experience to show that most people fail miserably at that. Also passphrases generated your way can easily be longer than many systems will accept. The latest NIST SP800-63b guidelines, linked above, require only 64 characters to be accepted. Your pink flamingo password is longer than that. And many (most?) systems do not even meet the NIST requirements. (Does Wikipedia?) And of course typing a passphrase that long without error, especially on mobile devices, is not easy. Making up a sentence using the random words is a great idea as a memory aid, but there is no need to make the sentence the passphrase.-- agr ( talk) 18:02, 25 November 2018 (UTC)

The diceware method is an excellent way of constructing a passphrase. I highly recommend it, especially if you use the EFF's long word list for five dice (or one die rolled five times). [6] Anyone using the diceware method instead of my method will also be insanely secure against both dictionary attacks and against brute-force guessing attacks. I have never heard of anyone or any computer program ever guessing a Diceware passphrase.

That being said, as you yourself pointed out in 2014, the four words that XKCD mentions (note that Randall Munroe never actually says that "correct horse battery staple" is sufficient, only that it is easier for a human to remember and harder for a computer to guess than "Tr0ub4or&3" is) are a couple of words too few:

"For the average user I now recommend a passphrase with six Diceware words, or five words with one extra character chosen and placed at random. This is a change from my previous advice [five words]..." --Source: The Diceware Security Blog

In my opinion (and this is a judgement call - I may be wrong), compared with my method Diceware is much more resistant to the well-known human tendency to make non-random, guessable choices, but (also IMO) my method gives you a passphrase that is easier to memorize and remember after a long time of not using it compared to a Diceware passphrase. -- Guy Macon ( talk) 07:02, 26 November 2018 (UTC)

Not intending to get into an argument with you, Guy Macon, just testing my understanding ... by, um, arguing. (Sorry!)

The horse said "That's a battery staple". I replied, "Correct!"

is clearly superior to

correct horse battery staple

(or whatever it was), all things being equal. But not all things are equal, it seems to me. If I want to log in here via my phone (which BTW is something I don't remember ever having done, and would be very reluctant to do), then I'd have to (i) remember the former precisely, (ii) paste it from text copied from elsewhere in the phone's memory (bad!), or (iii) read it off a piece of paper (bad!). As for my own computer, it's rare that I need to specify my password; when this happened, I wouldn't remember if I'd had "replied", "responded" or "answered" (etc etc); and if I'm reading it out of some file I might as well copy

correct horse battery staple bismuth fortuitous banana

(or whatever) out of it and paste that as do the same with the two sentences -- which are indeed hugely more easy for short-term human memory but I imagine [disclaimer: I am not a cognitive scientist] just about as hard, or possibly even harder, for precise memorization over a long period. (Or possibly the problem is that my memory is unusually crappy.)

I don't think what I'm saying contradicts what I understand as your main point, for which I'm grateful (and according to which I intend to upgrade some of my passwords). -- Hoary ( talk) 01:40, 26 November 2018 (UTC)

I am in basic agreement with you. It is significantly harder to compose a passphrase that doen't have significant "I replied\I said" memorization problems when you start with a list of words someone else chooses. I should modify my advice to talk about that. -- Guy Macon ( talk) 07:02, 26 November 2018 (UTC)

While I do recommend a six-word passphrase, a four word passphrase like correct horse battery staple is still far stronger than what most people use and is unlikely to appear in a list of previously hacks passwords. I don't disagree that The horse said "That's a battery staple". I replied, "Correct!" is stronger. The question is whether the improvement is worth the added typing. Your passphrase is 61 characters long, vs 28 for the original. I'm not aware of any way to quantify how much more entropy your passphrase gains over XKCD's original, but most people do fairly predictable things when given open-ended advice like make up a sentence with these words. My metric is bits of entropy per keystroke. In my view, entering passwords accurately is the biggest cost to users. Very few people are going to memorize more than a few strong pass phrases. That's why I recommend writing them down or using a good password manager with a strong master pass phrase. The threat these days is not someone stealing your wallet, it's lists of hashed passwords being stolen and cracked offline at very high speed, billions per second. My Diceware list was chosen to minimize word length, and hence passphrase size, for any chosen level of security. The EFF uses much longer words, which I think is silly, but it's a personal choice. Again making up a sentence from a random passphrase as a memory aid is fine, but using the sentence as as the passphrase itself is a very inefficient way to increase security. For what its worth, I also have a tool for generating mnemonic sentences from any random 10-letter string. Random letter strings may be a better choice for mobile devices, which are becoming more common than PCs as an Internet access tool. The best path forward, I believe, is stronger ways for storing password validation data so that stolen lists are much harder or infeasible to crack. That's been the focus of my recent research. How does Wikimedia store its passwords?-- agr ( talk) 17:08, 26 November 2018 (UTC)

To partially answer my own question, I found a page https://www.mediawiki.org/wiki/Manual:User_table that describes the Wikimedia default which is pbkdf2 with 10000 iterations of sha256 and salt. That's not bad, but a memory intensive algorithm like scrypt of argon2 (or my RockSalt) would be better. Still, the default shifts the likely threat to using a password that has been cracked before and is high on a list of common passwords.-- agr ( talk) 17:30, 26 November 2018 (UTC)

@ ArnoldReinhold: Just a minor correction to your comment, we are currently using PBKDF2 with 128000 rounds sha512 (and salt). [7]. BWolff (WMF) ( talk) 06:31, 5 December 2018 (UTC)

Guy Macon, I'm not clear about the advantage of including word spaces rather than using a continuous string. Is it just that it makes it longer without increasing the difficulty of memorization? DGG ( talk ) 20:01, 27 November 2018 (UTC)

Itdoeslittletomakethingsharderforanattacker(anyreasonablycompetentattackerwilluseadictionarythattrieseveryphrasewithandwithoutspaces,d1fferentc|-|aractersub5titutions,etc.),butitishardertorememberandeasiertomakeatypowhenyourpassphrasedoesn'tusestandardspelling,punctuation,andgrammar. Guy Macon ( talk) 23:59, 27 November 2018 (UTC)

I'd like to endorse Guy's principle, with one small addition: make sure your passphrase incorporates at least one unusual word – maybe one of your friends has an unusual name, or you know a place with a strange name, etc. Since the strength of a passphrase is directly related to the size of the dictionary needed for a dictionary attack, you can force an attacker to use a very large dictionary, and massively increase the time required to crack the passphrase by that means. Try something like My family and I stayed 14 days in Betws-y-Coed. HTH -- RexxS ( talk) 22:18, 29 November 2018 (UTC)

That's a very good adddition. Increases passphrase strength even more without making it harder for a human to remember. It would be a large dictionary indeed that contains "Betws-y-Coed". Thank you from the bottom of my parasagittal circumduction. -- Guy Macon ( talk) 00:03, 5 December 2018 (UTC)

The problem with a passphrase is that the risk of a typo is too high; and since I can't see the text I'm typing in, I can't even confirm that I typed it in correctly before clicking on the login button. In a passphrase of 40 characters, my chances of a typo are close to 100%; and in a password field, I can't even see it. עוד מישהו Od Mishehu 13:39, 9 January 2019 (UTC)

2FA is not just about "cracking" passwords

There's a huge amount of text here so I'm not sure whether the point has been made elsewhere, but I think it's worth calling out explicitly.

All the stuff about "Macon's principle" is fine, if the only thing you have to worry about is whether a password can be brute-forced. Unfortunately it isn't.

What happens if you need to log in from a public library or a Kinko's? There's probably no keylogger installed on the machine. But there could be. Are you going to come up with another seven-word meaningful and unguessable sentence and change your password?

With 2FA, you can go ahead and log in and not worry about it too much. Probably no one captured your password. But even if someone did, he/she will have a hard time using it. It isn't theoretically perfect, but it's pretty good, which in real-life situations sometimes has to be good enough. -- Trovatore ( talk) 19:56, 25 November 2018 (UTC)

• You just have an alt with a different password in those situations, which is what most admins do. TonyBallioni ( talk) 19:58, 25 November 2018 (UTC)

  OK, fine. What about if someone forges an SSL cert? You won't know when that might happen. -- Trovatore ( talk) 20:08, 25 November 2018 (UTC)

  Trovatore, An alternate account with 2FA on it as well? In any event when I go out, I never login to public devices. My laptop always comes with me. — CYBERPOWER ( Chat) 20:15, 25 November 2018 (UTC)

  Someone might use a forged cert to impersonate Wikipedia even when you're logging in from home, and capture your password. Look, the details aren't important. The point is that there are lots of ways passwords can be captured, not just brute-forced. If you have 2FA, you can accept these risks and relax a little bit. If you don't, you can try to figure out all the attack vectors, which is a full-time job for highly paid people, or you can accept the risks and just hope. -- Trovatore ( talk) 20:21, 25 November 2018 (UTC)

  Would the alt have admin privileges, even if clearly identified as a second account? -- Masem ( t) 17:13, 26 November 2018 (UTC)

Trovatore makes some very good points. There are indeed more ways to attack your login than just a brute force or dictionary guessing attack. Even the "In any event when I go out, I never login to public devices. My laptop always comes with me" method desribed above could be vulnerable to a hidden camera attack or an Evil maid attack. There was a case where an Israeli counter-terrorism unit hired a magician to do a quick swap of a cellphone sitting on a desk with the owner right next to it, some other spies in the next room quickly cloned everything on the cell phone into another one with some special hardware built in, then the magician did another quick switch. Also see: 11 ways to hack 2FA and Security News This Week: Oh Good, Hackers Beat Two-Factor to Rob Bank Accounts

In our case, we aren't terrorists or spies and are extremely unlikely to receive such individual attention. For us, the most likely attack is someone trying multiple Wikipedia accounts looking for a guessable password. A less likely but still plausible threat is someone bribing/threatening a key WMF employer, gaining access to our list of password hashes, and doing a high-speed brute force password-guessing attack.

2FA is fine, until someone concludes that 2FA means they don't have to choose a passphrase that is easy to remember and hard for a high-speed offline passphrase-guessing program to guess. -- Guy Macon ( talk) 07:42, 26 November 2018 (UTC)

Account security is only as good as its weakest point. Anarchyte ( talk | work) 08:30, 26 November 2018 (UTC)

...usually. If either guessing your passphrase OR faking your fingerprint will give the attacker access, then both your passphrase and the fingerprint reader have to be resistant to attack -- the system is indeed only as good as its weakest part. but if guessing your passphrase AND faking your fingerprint are needed to give the attacker access, the system is at least as good as its strongest part. -- Guy Macon ( talk) 00:10, 28 November 2018 (UTC)

2FA is a "both" scenario, though. If I turn on 2FA and make my password "password", an attacker still needs my rapidly-rotating and device-dependent 2FA token to log in to my account. Ivanvector ( ^Talk/ _Edits) 17:06, 6 December 2018 (UTC)

Parallel discussion

Trying to kick this thing back awake, and also noting that there are several other discussions regarding nearly-inactive admins at WP:BN right now that have some very interesting points, including lists of admins who have hung on to the tools despite not using them for 5-10 years or longer. Beeblebrox ( talk) 05:34, 6 December 2018 (UTC)

For the record, the WMF's own "make 2FA mandatory for admins" discussion is over here. Jo-Jo Eumerus ( talk, contributions) 07:05, 7 December 2018 (UTC)

Alternative better idea than mandatory 2FA

Admins would upload a .XYZ file when logging in. This file contains a 2048-bit public key that will be checked against Wikipedia's own Central Authority (for verifying Wikipedia admin account login purposes only), where each admin account has their own private key in PKCS 12 (.p12) file and a Certificate, on the server. Wikipedia would e-mail the public key files to the admins via the e-mail address registered to their account.

When the file is uploaded, the an internal verification server will decide by seeing if the public key provided in the file would be able to decrypt a message if it were to be encrypted via the private key on the server linked to the admins account. If it passes the verification, the login process is successful. If it fails, the verification server will request the Web host server to inform the client to display a access denied error message. Aceing_Winter_Snows_Harsh_Cold ( talk) 23:49, 8 December 2018 (UTC)

This is essentially still a 2FA: something you know (your password), something you have (this certificate; with the challenge of certificate management across many devices to worry about. — xaosflux ^Talk 17:23, 9 December 2018 (UTC)

Please join discussion at Template_talk:One_other_topic#Encourages_partial_title_matches about the guidance in the {{ One other topic}} template which encourages partial name matches.

As per the Disambiguation Dos and Don'ts, editors are not supposed to "include every article containing the title." The template basically guides editors to do just that. Coastside ( talk) 16:50, 24 January 2019 (UTC)