The latest series of compromised admin accounts apparently involved admins who re-used passwords, that is, used the same password for their Wikimedia login that they were also using on other websites. When one of these websites is subject to a security breach, hackers are able use the list of passwords to login to these users Wikipedia accounts and begin vandalizing the project. Users who edit under their real names are particularly susceptible to this specific form of attack as it is easy to link the two accounts.
In order to prevent this scenario in the future, it is proposed that Wikipedia:Password strength requirements, which is a binding policy for all administrators, bureaucrats, edit filter managers, and functionaries, be amended to require that these users maintain a password solely for their Wikimedia login. Users found to be in breach of this policy (as evidenced by their account being compromised in this same manner) may have their advanced permissions removed by the arbitration committee.17:09, 16 November 2016 (UTC) Striking this provision as it is proving a distraction from the core issue. Beeblebrox ( talk) 07:25, 19 November 2016 (UTC)

• Support as proposer. This shouldn't have to be spelled out, but apparently it was unclear to a number of admins. Beeblebrox ( talk) 17:09, 16 November 2016 (UTC)

  Request clarification. When you say "solely for their Wikimedia login," do you mean it for everything under our "global" Wikimedia account? And requiring different passwords is meant for any site outside of our global account? — Maile ( talk) 17:24, 16 November 2016 (UTC)

Per WP:SUL, all accounts are global, and have been for some time. Beeblebrox ( talk) 17:35, 16 November 2016 (UTC)

WP:SUL lies then :) If you've got an account to Wikitech/LDAP/Gerrit/etc, that's a different account. Same with some fishbowl wikis like wmfwiki. So yeah, if you've got multiple accounts they need different passwords. ^ demon ^{[omg plz]} 17:46, 16 November 2016 (UTC)

Upon closer inspection, it does say "most" WMF sites. The point here is that our admins should be using a unique password for their admin accounts. Beeblebrox ( talk) 17:58, 16 November 2016 (UTC)

Indeed! And not just admins, everyone should be exercising good password practices. This means not reusing passwords, making sure they're secure (most people say 8+ chars, I suggest 20+!), rotating them from time to time and enable 2FA when and where you can. This applies everywhere, not just Wikimedia :) ^ demon ^{[omg plz]} 18:01, 16 November 2016 (UTC)

• Support as plain and simple common sense. Ritchie333 ^{(talk) (cont)} 17:23, 16 November 2016 (UTC)
• I am under the impression the ARBCOM desysop procedures already allow for emergency desysopping due to compromise. This proposal should require, if your intent is to be made correctly, that ARBCOM may remove permissions from 1) any user 2) permanently. That said, this proposal seems to have no effect in that a user may re-request the tools and subsequently be granted them without anyone the wiser to the fact the user may or may not have changed their password to a stronger/different password. In that regard, I would oppose the suggested amendment. -- Izno ( talk) 17:28, 16 November 2016 (UTC)

  Additionally, I see no reason why ARBCOM should have this power when any user with the correct permission set should be able to execute on this problem when it is first noticed. -- Izno ( talk) 17:38, 16 November 2016 (UTC)

  Just because a user can re-request the tools at WP:BN, doesn't mean the 'crats are obliged to hand them over. I understand the policy to basically cover the recent cracks; even if your password is long enough and not amongst the most obvious, but is still reused on another site, policy will allow an emergency desysop even if the account did not perform any compromised activity on-wiki. Ritchie333 ^{(talk) (cont)} 17:40, 16 November 2016 (UTC)

  Which perhaps misses my point: If we have no evidence (and we cannot per the privacy laws the WMF operates under) that the passwords have changed, then it seems we cannot enforce this desired mandate. -- Izno ( talk) 17:43, 16 November 2016 (UTC)

This is true, it is sort of an "honor system" but if it were policy, we would be permanently removing admins who fail to take basic security measures with their account in the event that they are compromised, instead of just letting them right back in as we do now. . Beeblebrox ( talk) 17:46, 16 November 2016 (UTC)

• Support as basic security practice, the need for which is evidenced by the recent compromises. -- AntiCompositeNumber ( Leave a message) 17:36, 16 November 2016 (UTC)

  Even if we aren't de-sysopping, this is still basic security practice. It is very close to being the least you can do to make yourself safer. -- AntiCompositeNumber ( Leave a message) 23:49, 20 November 2016 (UTC)

• Support We can prevent further compromise by raising the cost for admins whom are not in compliance. Chris Troutman ( talk) 18:05, 16 November 2016 (UTC)
• This is security theater. Reusing the same password on different sites is, yes, a worst practice and we should of course advise against it. Strongly. But the assumption made here that all compromises are because of such reuse is unjustified. There's no way to know that for certain, not even in retrospect. If you want to propose that any account compromise should result in permanent removal of permissions, then propose that directly. — Cryptic 18:11, 16 November 2016 (UTC)

I don't see where I or anyone else have said that all compromises are caused by this, but WMF staff is saying that this recent batch in the last few days appear to be a result of password reuse. Beeblebrox ( talk) 18:37, 16 November 2016 (UTC)

"as evidenced by their account being compromised in this same manner". Absent something extraordinary like the current hacking group disclosing their sources and methodology, you're not going to find a statement from WMF technical staff that isn't littered with qualifiers like "appears to be", "fairly sure", "consistent with". In an isolated breach of only one or two non-Jimbo accounts, you're not going to get even that. So the permission-removal statement is either toothless and will never be invoked, or so vague as to apply to any account compromise. I'm not seeing a middle ground here. — Cryptic 20:05, 16 November 2016 (UTC)

The objective here is primarily to prevent further breaches. As for the part about arbcom, I simply used some wording already in the current policy. This is more just a matter of getting this idea into the policy in order that users with advanced permisssions understand how important this is and comply with it. I fully admit there is no real way to police it, that isn't really the point. Beeblebrox ( talk) 20:59, 16 November 2016 (UTC)

• Support Again, same rationale as before. Chris Troutman ( talk) 14:48, 20 November 2016 (UTC)
• Support, but note that enabling two-factor authentication would have prevented compromise, even if you shared the password. I strongly advocate a unique, strong, password as well as two-factor authentication. That's not what's being discussed, though. I support requiring users maintain a password solely for their Wikimedia login. -- Yamla ( talk) 19:29, 16 November 2016 (UTC)
• Support I can't see a good reason not to implement this. Mike V • Talk 20:28, 16 November 2016 (UTC)
• Support. It's not enforceable, but hopefully most will be honorable enough to actually do it if it's policy - and any who don't and are hacked as a result should then lose the admin bit. Boing! said Zebedee ( talk) 21:11, 16 November 2016 (UTC)
• OpposeNeutral. Getting users with advanced permissions to use secure passwords would be nice, but revoking their status for being hacked gives power to the hackers. Do we believe a hacker if he says that he got the password off Twitter, or if he leaks a Twitter password file that appears to show reuse? Do we punish an admin if he comes out and says "the only other site I ever used this on was...", thereby making him afraid to tell us where the hackers got the data? Also, this would be a power play on a case by case basis - this comes right after the Jimbo Wales hack, and is anyone proposing to revoke his privilege? There is another way to do this - require the admins to change their password to something that starts with a certain letter and ends with a certain number. That would be annoying, but it would be enforcement-free. Wnt ( talk) 21:19, 16 November 2016 (UTC) The change is sufficient to allay the worst of my concern, and apart from lingering concerns that enforcement, even after "repeated" lapses if that ends up meaning two, would benefit hackers with an agenda, this is a worthwhile recommendation to make. This continues to be something that seems better addressed technically such as how I described previously than by policy. Wnt ( talk) 01:31, 24 November 2016 (UTC)
• Oppose the Arbcom teeth to this change. Arbcom can already discipline admins who do not uphold community standards. It would be more effective to mass message admins to remind everyone of good password hygiene. (I don't believe the change to admin password policy at the end of 2015 was ever mass messaged to all admins.) Espresso Addict ( talk) 21:36, 16 November 2016 (UTC)

The policy already says this with regards to the existing rules, so it's not actually a change at all. Beeblebrox ( talk) 21:41, 16 November 2016 (UTC)

Actually I don't think that's correct; as far as I can see, the original RfC did not mention formal Arbcom sanctions, so any wording was included by the policy drafter, who appears to have been you. Espresso Addict ( talk) 22:10, 16 November 2016 (UTC)

See below for an explanation of why it didn't need to be mentioned in the RFC as it was already policy. Beeblebrox ( talk) 00:27, 17 November 2016 (UTC)

• Oppose, if my account is compromised how will you know whether it's because my account is used on another site that was breached, or because I had a weak, easily guessable password? You don't. Therefore you can never enforce that my password is used solely for Wikimedia. Step hen 07:07, 17 November 2016 (UTC)

• This policy is not designed to be explicitly enforced, obviously. I see it as a formal reminder for all users to secure their accounts and to take password strength seriously - FASTILY 09:28, 17 November 2016 (UTC)

• Yes, it's designed to be enforced, both in binding policy and the wording of this proposal. It can't be enforced because you don't know the breach reason. Step hen 09:56, 17 November 2016 (UTC)

• Support per Common sense. - FASTILY 09:28, 17 November 2016 (UTC)
• Support again, same rationale - FASTILY 22:43, 20 November 2016 (UTC)

• Comment. There are a number of ways someone can get access to an admin account: not logging off on a public machine, leaving a home machine open when friends and family are around, having an unlocked phone stolen (some phones don't lock when the user is in motion so if the phone is stolen from a bag or pocket while the user is in motion - train, bus, etc, it would be unlocked), falling victim to an email scam ("Your Wikipedia admin account has been hijacked - to prevent damage to Wikipedia, log in here now to recover your account"), etc. Some admins already use a separate non-admin account for when they are travelling, etc, and some admins are savvy enough to not fall for a scam, but with all the ways there are that someone can get access to an admin's account, having a focus here just on passwords may give some admins a false sense of security if they create a strong password. I'm also not seeing a need for a separate page which essentially says little more than what is already on Wikipedia:User account security, so my feeling is that we should merge this page into Wikipedia:User account security and beef up the advice already there. Putting passwords into context of a wider awareness of what admins can do to ensure the safety of their accounts is more useful and safer than dealing with it as a discrete unit. SilkTork ^{✔Tea time} 10:50, 17 November 2016 (UTC)

• Oppose Still oppose simply because it cannot be enforced. I also suggest we wait on proposing something like this as I suspect many of the "support"s above could be because of the recent breaches. We should wait until we're done panicking to propose something like this. — Gestrid ( talk) 21:12, 17 November 2016 (UTC)

Of course this is because of the recent breaches. We have discovered that a number of our admins, and even Jimbo, were not following security procedures so basic we didn't even bother including them when this policy was created a year ago. I consider this an emergency fix to try and stop these breaches. Waiting serves nobody. The idea here is as much about getting the word out to all admins as anything else. I readily admit that in most cases it will not be enforceable, but there is no reason for any user with advanced permissions not to be doing this. Beeblebrox ( talk) 22:06, 17 November 2016 (UTC)

Update: My !vote still stands, as the policy still isn't enforceable. I've unstruck my oppose because of this. However, it's a good idea and I would suggest someone that someone make an essay about it. — Gestrid ( talk) 22:15, 20 November 2016 (UTC)

• Oppose Still oppose too draconian and too much bureaucracy. I posted a technical counterproposal further below (advanced permission holders must use server-generated random passwords). The "Passwords" section of Ross Anderson's security engineering book ( here, start on page 31 of the book) is worth a read for those who want a detailed treatment of this subject. 50.0.136.56 ( talk) 00:54, 18 November 2016 (UTC) Added: the existing page is already too obnoxious and pretentious. The recommendations aren't actually bad, and adding password uniqueness to the list should have been an ordinary edit subject to BRD (instead of needing a UN resolution), but the page itself should be turned into a help page or something. 50.0.136.56 ( talk) 08:57, 7 December 2016 (UTC)

• Neutral Beeblebrox I share your frustrations that you have expressed on this page. I also toss kudos your way for trying to do something about the current compromise problem. However, I'm staying neutral on this idea, because I don't see how it could be implemented without some serious breach of privacy beyond Wikipedia. Just for the record, my Wikipedia password is used nowhere else. But if I was careless enough to reuse the password elsewhere, and all sites got compromised, I'm not sure how Wikimedia would know about the other sites. And if they did know, it would totally freak me out, and I don't know how it could be proven which site got compromised first, Wikipedia or the others. More precisely, I believe it would be the better part of wisdom for Wikimedia to at least lock down the tools on inactive admin accounts. If they fail to do that, the burden kind of rests on their shoulders. — Maile ( talk) 22:47, 17 November 2016 (UTC)

• Support - It's common sense!, I mean if you've ignored the various discussions and have been under the illusion of "oh my account won't be hacked" then you're an idiot and deserve to have your tools stripped - I'm not sure how it can be enforced but either way it somehow should be, If I was an admin and heard about this I'd change my password in a heartbeat and would do the whole 2FA thing too - It's common sense. – Davey2010 ^Talk 02:30, 18 November 2016 (UTC)

• (I've partial struck in light of the stripping bit being done away with however I still support the proposal here. – Davey2010 ^Talk 16:42, 20 November 2016 (UTC))

Out of interest what other common sense protections have you put in place to ensure your account doesn't get stolen? The security advice so far appears pretty minimal. A super duper very sophisticated heck I'm proud as punch Wikipedia password is not effective if someone has enabled their phone browser to remember it, and their phone isn't secure enough and it gets stolen. There are other scenarios to explore. By dealing with passwords as a separate and discrete unit of security protection we give users a false sense of security if all they are doing is making their password safe, but leaving other doors open. Security has to be a complete package. Put the world's most sophisticated lock on the front door, but then leave the key under the mat, and it becomes useless. The protections currently being discussed are against deliberate targeted attacks, but also likely are casual invasions when a weak phone is stolen, and fairly common are other occupants of a house using someone's machine. Perhaps we should be looking into should the software automatically log out admins after 30 minutes of inactivity, same as banks do. That's probably more common sense than a single site password used on a permanently logged in account. SilkTork ^{✔Tea time} 10:16, 18 November 2016 (UTC)

"Put the world's most sophisticated lock on the front door, but then leave the key under the mat" is indeed the way most hacks work. And yes, security should be a whole package. But the extreme of doing something like force logging out admin accounts after 30 minutes inactivity could have the adverse effect of driving people away. I have 2FA set up, for example (with the 2FA app on a device which is not, and never will be, logged into my Wikipedia admin account). My desktop and laptop computers have strong login passwords, and nobody else has access to them (and if one was stolen, I should have plenty of time to change my Wikipedia security from another device along with anything else - my passwords are not stored on a computer). And if I kept getting logged out and was forced to log in using 2FA and 2 devices multiple times every day (as opposed to, say, once a week for my bank), I'd do a lot less and would probably think about giving up admin. Boing! said Zebedee ( talk) 11:11, 18 November 2016 (UTC)

I agree. I wouldn't actually want to be logged out of Wikipedia. Personally I don't think that such levels of security are needed. Nothing significant can happen if an account is compromised. There may be some vandalism, perhaps some individuals blocked, but all of that can be put to rights soon enough so there won't be any significant or permanent harm. But I also think that 2FA is a step too far, making use of Wikipedia too awkward for casual use, and I would prefer to resign my tools than go down that route. But that's what discussions are for, isn't it, to find out exactly what levels of security we want or need. What I think is important is to give folks some sensible all round advice, so having a single page for that would be better than having this Wikipedia password only page. Any Wikipedia password is only as good as a user's email password because users can always have a new password emailed to them. SilkTork ^{✔Tea time} 18:55, 18 November 2016 (UTC)

While for my own sake would not want to have enforced 2FA, sysops can insert arbitrary javascipt for all site visitors. That can have significant security consenquences. BethNaught ( talk) 19:07, 18 November 2016 (UTC)

2FA shouldn't be enforced for ordinary users or admins, but I'm glad it's being made available for those who willing to use it. It makes the password situation much less sensitive. 50.0.136.56 ( talk) 09:27, 7 December 2016 (UTC)

• Oppose For the reasons I outlined above, and also in response to Davey2010, that we should be looking at admin account security as a complete package. Some of the support comments are giving me cause for concern as there appears to be a feeling that once an admin has a single site password, sufficient due diligence as regards security has been done. I think it would be more helpful to redirect this page to Wikipedia:User account security, and expand that page to deal with all the ways that admins can make their accounts more secure. We might also want to explore auto-logging off, or at least consider if we should be allowing admin accounts to remain logged in for up to a year. I wouldn't want auto-logging off, but I think we should be discussing it, as well as other security measures, all on the same page. SilkTork ^{✔Tea time} 10:16, 18 November 2016 (UTC)

Do you not think that mandating the use of a password unique to Wikipedia would be a good idea as part of a complete package? Boing! said Zebedee ( talk) 11:22, 18 November 2016 (UTC)

I think if we are interested in security, this page is dangerous as it leads users into a false sense of security which could lead to their accounts being compromised. I am not a security expert, but even I know that a secure Wikipedia password is useless if other security steps are not taken. People enthusing that this page is common sense gives me serious cause for concern. SilkTork ^{✔Tea time} 18:55, 18 November 2016 (UTC)

I see your point, in that a password is not all that is required and all admins should now be using WP:2FA and being otherwise careful with access issues as well, but redirecting a policy that was approved by the community doesn't seem like the right move. In both of the most recent serious security breaches, passwords were in fact the mechanism used to gain access to accounts. Links to other best account security practices could be made more prevalent here in order to clarify that just having a good password isn't enough. Beeblebrox ( talk) 19:32, 18 November 2016 (UTC)

I take your point that passwords were used to gain access in the recent situation, so making people aware that weak passwords and passwords used in multiple locations are vulnerable is sensible. My concern is that by focusing only on passwords on this page we are like a family living in a house in which the back door is open, the kitchen window is open, the side door is open, and the front door has a weak lock. Some burglars break in through the front door, so quite wisely we strengthen the locks on the front door. Then we gather the family to talk about how further we could strengthen the front door, and we agree to put on triple locks and use a security key. We all then go out to the pub confident that we have done everything we can to secure the house. Meanwhile all the other routes to the house are still vulnerable. My point here is that it is much more efficient and effective to gather the family once to discuss all security weakness and how best to fix it. Or, put it another way, put all our security advice in one place where it can be updated as appropriate without people having to check several places. Passwords are only one part of ensuring Wikipedia is not inconvenienced. I would welcome our experienced and knowledgeable users working together in one place to produce a useful guide to security. The alternative is having a page here for passwords, then another one somewhere else to tell admins to log off, another one discussing how best to use phones, another one talking about accessing admin accounts on public machines and the consequences to admins if someone then gains access to their account and rampages through Wikipedia blocking their friends as a joke, etc. The more pages we have the less likely it becomes that an admin will visit them all and keep up to date. SilkTork ^{✔Tea time} 08:55, 19 November 2016 (UTC)

@ SilkTork:, could you please give examples of such security breaches in Wikipedia/Wikimedia which are not related to passwords? Imagine I have a password which I reasonably do not expect to be hacked (and I have some good reasons to believe it to be the case); what else should I worry about? I genuinely do not understand.-- Ymblanter ( talk) 17:50, 19 November 2016 (UTC)

I have mentioned several on this page. Using a public machine and not logging out. Having a weak email password, so someone gets access to that, then emails Wikipedia for a new password. Leaving your home machine logged in when friends or family are present. Sure it is friends or family, so nothing malicious will happen, but the experience could still be awkward and embarrassing. Using a smart phone to access your admin account; a phone can sometimes be unlocked when being carried. Email scams in which you are asked to log onto your account on a false Wikipedia page. I'm not very security conscious - I'm sure someone who is could advise you of others. I think we need a page of general advice to admins on ways to sensibly protect their account. Personally I never access any vulnerable sites on my phone because even though I have a password for it, and it locks itself automatically after a certain period of inactivity, it only takes a moment of distraction (and thieves are pretty expert at this, as distraction is the key to phone theft) to steal a phone that has recently been used so is still open. Let's be honest, the thieves wouldn't be interested in your Wikipedia account, they would be interested in your email and bank account, but while they have it, they might just play around with your admin account for the fun of it. SilkTork ^{✔Tea time} 19:29, 19 November 2016 (UTC)

Tnx, now it is clearer to me what you mean.-- Ymblanter ( talk) 20:12, 19 November 2016 (UTC)

• Oppose Still Oppose per above: I don't think that strong passwords isn't a requirement here but I usually change password every 6 months or when nesscerry upon future adminship. KGirlTrucker81 ^{huh? what I'm been doing} 00:01, 19 November 2016 (UTC)

@ KGirl: i've read this five times and can't see an explanation of why you oppose this.

Frankly, it's gibberish. Beeblebrox ( talk) 03:18, 21 November 2016 (UTC)

KGirl, it's now considered better to make a very strong password and keep using it, than to change it frequently (which leads to choosing simpler ones that are easier to remember, therefore easier to break). [1] Just so you know. 50.0.136.56 ( talk) 09:10, 7 December 2016 (UTC)

• Strong Oppose - just perpetuates the problem and presumes perhaps wrongly. Just a loaded question/presumption of blame the user and removing them is a show of 'doing something' rather than a prevention. FIX THE SYSTEM INSTEAD. If you want better passwords, then have the _system_ make them up and you've fixed it so the problem can not happen rather than shooting the occasional admin after damage is done and possibly for a wifi hijack or keystroke capture that is not at all a password flaw or user fault. If you instead had a system with assurance that passwords are decent, then when (not if) hacks get in, you at least know it's not a bad password. Markbassett ( talk) 00:29, 19 November 2016 (UTC)

I can see now that I made an error in even mentioning consequences, which would be the same for this policy as for any other policy that is binding on admins, that is, if an admin seriously, repeatedly fails to abide by it their may be consequences. The main goal here is to just get admins not to recycle their passwords, not to get rid of admins for one mistake. Beeblebrox ( talk) 03:15, 19 November 2016 (UTC)

I think the consequences part is less of a specific issue than a sign of too much micromanagement in the overall document. To the extent possible, we should avoid telling users what to do. Rather, as Markbassett says, we should fix the software so the right thing happens automatically. I mentioned elsewhere that the venerable Rainbow series security manuals also recommend that approach. 50.0.136.56 ( talk) 03:54, 19 November 2016 (UTC)

• Still strong oppose - the stopping just short of penalty and striking out opinions is just further mangling this RFC. Look, the presuming the problem is X and making policy for that instead of a system fix or imagining the other ways hacks happen, is proceeding down the easy blame the victim path and painting it into a corner of going to be a punishment --- obscuring that for now does not make it less inevitable a course or any more helpful to WP or to the victim. Trying to make it look like the victim isn't being punished -- when where else can it go -- or not a blind assumption -- since it's not provable -- does *NOT* make this better. FIX THE SYSTEM so this problem cannot happen, then when (again, not 'if') the next hack happens you know it's not the victims fault in this way. Assign a password, not choose one, and move on. Markbassett ( talk) 21:41, 20 November 2016 (UTC)

• While we should tell Admins to not reuse passwords, and Arbcom has the authority to desysop for repeated breaches of policy, I don't think a special desysop standard for password reuse is appropriate. Instead, we should focus on improving security culture, which includes avoiding this type of password reuse, but needs to be much broader. We can't, and shouldn't try to legislate perfect security practices by policy, but should instead focus on awareness. Monty ₈₄₅ 04:47, 19 November 2016 (UTC)

But..it's not a "special desysop standard". It's just a statement of the well-astablished fact that arbcom can desysop an admin who repeatedly fails to uphold expected standards of admin behavior. I could have left it out of the language of the proposal and it would till be true anyway. (And since it is distracting from the real issue here I certainly wish I had done exactly that). Beeblebrox ( talk) 04:56, 19 November 2016 (UTC)

• ArbCom would need to install telescreens in order to detect this. One cannot prove easily that a compromised account was not due to password reuse. There are other common reasons for a compromised account: keyloggers, for example. How will it be proven that an admin has reused passwords without knowing what the admin's password is, or at least what the hash of the password is? Will the editor handling this can be trusted, without causing any more damage in the process or handling another editor's password, which may be used on other websites, securely. Esquivalience ( talk) 05:52, 19 November 2016 (UTC)

So getting all hung up on it is meaningless and the real point, that admins should not be recycling passwords, should be the focus of this discussion. That being the case I have stricken it so we can get on with discussing the part that is the actual point here. Beeblebrox ( talk) 07:25, 19 November 2016 (UTC)

• Support this is clearly good, recommended practice and admins should be doing it. Is is unenforceable? Yes, generally speaking, but including this would be useful in spite of that. If we add this then admins will know it is expected of them and they will be more likely to do it. The idea of forcing people to use server-generated random passwords is a non-starter from a usability perspective as nobody will be able to remember them, which will likely lead to people writing them down. Hut 8.5 10:59, 19 November 2016 (UTC)
• Oppose - If an individual within the groups that would be affected uses their password that they use here for something elsewhere, how can we control their action in that respect, know they did so, or prove that they did so? I have no problem with strongly suggesting it, but adding it to the books as mandatory serves absolutely no purpose.—  Godsy ^{( TALK} _CONT) 12:54, 20 November 2016 (UTC)
• Comment  The RfC proposer changed the proposal yesterday [07:25, 19 November 2016 (UTC)].  There are already two !votes cast for the 2nd proposal [10:59, 19 November 2016 (UTC) and 12:54, 20 November 2016 (UTC)].  So the above !votes are a confounding of responses to two different RFCs.  I am resetting the rfcid, striking the !votes made to the first proposal, and pinging those editors to update their !votes.  Also for one IP editor I am posting a comment on their talk page. 

@ Ritchie333, Izno, AntiCompositeNumber, Chris troutman, Yamla, Mike V, Boing! said Zebedee, Wnt, Espresso Addict, Stephen, Fastily, Gestrid, Davey2010, SilkTork, KGirlTrucker81, and Markbassett:  Unscintillating ( talk) 14:24, 20 November 2016 (UTC)

I'm not sure any of this is helpful - this discussion in itself, changing the proposal part way through, or striking users' comments. My point is not changed by part of the proposal being struck. My view still holds that this page is best merged with the main security advice page, and once this RfC is over I may start a merge discussion. At the very least a merge discussion may raise some awareness that we shouldn't be dealing with security as solely a password issue, and need to be aware of other ways we can keep our accounts secure. SilkTork ^{✔Tea time} 17:17, 20 November 2016 (UTC)

I'm also unclear why people are objecting to the sentence which has now been struck from the proposal, given that we have a history of dysysoping admins whose accounts have been compromised, so there is precedent. I was one of those who dysysopped the last one on that list. SilkTork ^{✔Tea time} 17:30, 20 November 2016 (UTC)

i know, and I tried to explain that it wasn't some radical new idea, but a number of users seemed fixated on it, and the real point here is to get this into the policy, raising awareness of this simple security precaution, and that sentence was getting in the way of that goal. Beeblebrox ( talk) 03:18, 21 November 2016 (UTC)

• Oppose A rule that is impossible to enforce is a useless rule.  — Scott • talk 14:50, 24 November 2016 (UTC)

@ Scott: It is more advice han an enforceable rule, but it is advice that a number of our admins apparently were not aware of. The point here is to raise awareness in order to prevent further breaches. If awareness of this prevents just one admin account, ever, from being hacked it has a use and a purpose. Beeblebrox ( talk) 19:53, 25 November 2016 (UTC)

If it's advice, it's not a rule, so you shouldn't be trying to propose it as one.  — Scott • talk 20:35, 27 November 2016 (UTC)

• Oppose: as unenforceable. BethNaught ( talk) 20:57, 27 November 2016 (UTC)
• Oppose - making a moral panic over inactive admins and weak passwords isn't really useful here. After the series of compromises, which is now over, no lasting damage was done. It's all good. Making symbolic rules to demonise those who are compromised isn't going to do much of anything. -- Ajraddatz ( talk) 06:03, 29 November 2016 (UTC)
• Oppose Due to the fact that there is no way to enforce this, it is merely another useless policy that will have little to no impact. Yes, it is a good habit to have unique passwords for all sites, but it doesn't mean much if a user uses all unique passwords, yet a mangling or markov attack using the compromised password will most likely work. If the foundation wants to significantly reduce their attack surface for privileged accounts, they should mandate two-factor authentication not some generic policy that has no weight. Additionally, the foundation should have no idea what is the user's password on wikipedia and therefore can't compare it to a list of breached accounts unless they are an active participant in the usage of such data. Jab843 ( talk) 14:48, 2 December 2016 (UTC)

General discussion

While it is true that this is unenforceable, except in retrospect, the idea is to raise awareness of this issue. I would have hoped that users with advanced permissions were already doing this, but clearly not all of us are. Beeblebrox ( talk) 17:52, 16 November 2016 (UTC)

Raising awareness is all this does. Can you imagine ARBCOM desysopping an admin purely because they were sloppy with password usage? I know a few beloved admins that could return to RfA the very next day and pass with flying colors. I don't think there's political will for this and this proposal doesn't actually bind ARBCOM to any course of action. I think internal WMF audits of passwords make more sense but we can't make WMF do anything so this is the next best choice. Chris Troutman ( talk) 18:05, 16 November 2016 (UTC)

We approved those audits about a year ago, and at the time it seemed like the foundation was on board with it, but yeah, as far as I am aware there has never been one. Beeblebrox ( talk) 18:39, 16 November 2016 (UTC)

Not a geek or anything, but I was wondering is it possible to implement this kind of security?— UY Scuti ^Talk 18:55, 16 November 2016 (UTC)

• Ragarding two factor identification: The problem with requiring that for admins is that in order to do it you must have a smart phone with a third-party app on it. There is no way we can require admin to have a smartphone. Beeblebrox ( talk) 19:51, 16 November 2016 (UTC)
  • No, you don't have to have a smartphone - you can do it all on your desktop or laptop computer (for the 2FA that's been implemented at Wikipedia at least). Boing! said Zebedee ( talk) 21:07, 16 November 2016 (UTC)

Really? When i went to do it last night, it very clearly instructed me to get my phone, download an appropriate app, and scan the qr code. If there's some other way it works that needs to be a lot more clear in the preferences menu. Beeblebrox ( talk) 21:40, 16 November 2016 (UTC)

Yep, I think it might be described at the AN discussion, but there are apparently apps for Windows and Mac that will do the same thing. I used the Google app on my iPad, but even then I had an option of scanning the QR code or entering the keys manually. Boing! said Zebedee ( talk) 21:52, 16 November 2016 (UTC)

See this guide for more info on that desktop TOTP client -- samtar ^{talk or stalk} 11:07, 17 November 2016 (UTC)

There seems to be some confusion about the language regarding arbcom, apparently stemming from unfamiliarity with the current policy, which already says arbcom can desysop any admin who fails to maintain a strong password. You'll note the proposed new language says "may" not "must". It will be up to the committee to pursue such cases or not, as it already is regardless of the outcome of this discussion. This is not actually a change from the established policy and therefore not really worth arguing over. Beeblebrox ( talk) 21:47, 16 November 2016 (UTC)

I'd argue, as above, that this part of the current policy was not mentioned (as far as I can see) in the supporting RfC and thus is not actually policy. Espresso Addict ( talk) 22:10, 16 November 2016 (UTC)

I thin you are missing the point that any admin who persistently fails to adhere to expected standards is subject to being desysopped by arbcom. The policy simply states what is already fact. Administrators who seriously, or repeatedly, act in a problematic manner or have lost the trust or confidence of the community may be sanctioned or have their access removed. That's been our policy for quite some time. Beeblebrox ( talk) 00:22, 17 November 2016 (UTC)

No, you are missing my point that (because of the policy you link & Arbcom current practice) there is no need to repeatedly bring Arbcom sanctions into everything to do with administrators whose behaviour diverges from perfect. My main point is that you appear to be needlessly turning this matter into a battleground. Nearly everyone agrees that admins should use a unique password to access their admin a/c. Bringing in formal sanctions for those who trip up (once, accidentally) seems entirely counterproductive. We should be focusing on how to reach tech-phobic admins, not how to beat people with sticks after their account has been hacked. Espresso Addict ( talk) 00:50, 17 November 2016 (UTC)

(ec) I'm just coming in to this from central discussion, so I don't really understand. @ Espresso Addict: The current version of this says, and has said since November 2015, [2] that "Users with advanced permissions who are found to be out of compliance with these requirements may have their permisssions revoked until they have made adequate assurances that they have rectified the issue. Users who repeatedly fail to maintain a strong password may have their permissions permanently revoked by the Arbitration Committee." This provision is similar to but not the same as what is proposed at the RFC, which makes it sound like a single compromise puts the admin's credentials in jeopardy as more than just a temporary measure. The definition of "repeatedly fail... may" is prone to different understandings though; I'd take it to mean someone who is absolutely obstinate rather than someone who screws up twice. And "strong password" is similarly prone to interpretation - we normally see that defined by some piece of software that is judging your 'entropy' as you type; it is not obvious to me that password reuse means that you failed to have a strong password per policy. As I argued in my vote, I don't want any one hacker to have a path to get admins thrown out if they cross him.

As we push on the admins we need to remember that every action has a reaction. If we demand a unique password for Wikipedia, the odds that it is written down on a piece of paper, or in a file that an attacker might get at remotely, or held in some third party company 'secure keyring' that gets hacked at their end will probably go up.

I think that positive methods to help security would work better than threats, and I feel like there has been very little creativity applied to this problem. We have a world-class collection of images to help focus users' memory on passphrase components, for example. Wnt ( talk) 00:29, 17 November 2016 (UTC)

See my response to Beeblebrox above. We need to focus on persuading tech-phobic admins to adopt safer passwords, not punishing admins who make a mistake. Espresso Addict ( talk) 00:50, 17 November 2016 (UTC)

All I can say is that it feels to me like I am not the one making a big deal out of nothing, and there are no "formal sanctions", simply a statement of long-established policy. Beeblebrox ( talk) 00:57, 17 November 2016 (UTC)

Well, hacking is all about making a big deal out of nothing, because it flies in a tight military formation with cyberbullying. They hacked Sony and were able to hound Amy Pascal right out the door because she suggested "black" films for an event with Obama - even as the main pay cable networks run openly segregated stations! And then there was the thing with the DNC, and so on. We can expect that a hack will be coordinated with making a big deal out of nothing, so we have to make a big deal out of nothing, or out of the ability to potentially make a big deal out of nothing, before it happens. Wnt ( talk) 01:02, 17 November 2016 (UTC)

We might have even gotten President Trump because of the embarrassing Clinton campaign emails extracted from John Podesta's gmail account that used a weak password (he apparently ignored advice to use 2FA) and published by Wikileaks in the final weeks of the campaign. I doubt the disclosure actually flipped many votes, but it may have led some wavering Clinton supporters in tight swing states to stay home, maybe enough to change the outcome. Whether that's good or bad of course depends on which candidate you wanted. 50.0.136.56 ( talk) 04:02, 19 November 2016 (UTC)

• Oppose, since the policy could not be enforced, as there is no way to check, if a given passphrase was not used elsewhere.

That being said: Of course, using a sufficiently strong passphrase is a necessity everywhere in the internet. Wikipedia is no exception.-- *thing goes ( talk) 09:32, 26 November 2016 (UTC)

• Reading suggestion People wanting to see some academic discussion of password management might look at Ross Anderson's book Security Engineering, chapter on passwords, starting on page 31 of the book (page 15 of the linked pdf). 50.0.136.56 ( talk) 01:00, 18 November 2016 (UTC)
• I oppose a requirement which cannot be enforced, but broadly support taking steps to educate all editors with advanced permissions about password security. A mass message detailing proper steps to secure your account would be reasonable, for instance. Such a message should target bureaucrats, administrators, account creators, and template editors, at a minimum. ~ Rob₁₃ ^Talk 10:30, 29 November 2016 (UTC)

  We already had one. -- Redrose64 ( talk) 00:27, 30 November 2016 (UTC)

  That was framed mostly as a pro-TFA message. Some administrators aren't going to use TFA for various reasons. I'm suggesting more of a general mass message on "best practices" for passwords. ~ Rob₁₃ ^Talk 03:38, 30 November 2016 (UTC)

  There's a NIST document with some updated recommendations now ( precis with links). It's more intended for system implementers but maybe there's some usable material there. 50.0.136.56 ( talk) 08:45, 7 December 2016 (UTC)