Jump to content

Wikipedia talk:Password strength requirements/Archive 1

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
Archive 1

Drafted

I've drafted the language for the new policy, but such things can always use extra eyes to make sure I've correctly interpreted the results of the RFC and worded it in a way that normal huans can understand before marking it as policy. Some of it is a bit vague, as the exact nature and timing of the auditing seems a bit vague, and the other measures such as the password strength bar and the list of common passwords are not yet in place. Beeblebrox (talk) 20:59, 13 December 2015 (UTC)

Seeing as the only edits have been a minor correction or two, I have gone ahead and marked this as policy and created some shortcuts. Beeblebrox (talk) 01:34, 21 December 2015 (UTC)
@Beeblebrox: While the RfC did close with explicit support for "most 10,000 passwords", several people said we don't know how we could implement that, and other comments gave the impression it was merely checking for some amount of common passwords, rather than specifically this number, that was important. Perhaps we could change "10,000" to "most common", which leaves more leeway to implementation. Ritchie333 (talk) (cont) 11:44, 21 December 2015 (UTC)
"Most common" leaves way too much leeway - "top 10 most common?" "top 1,000,000 most common?" - however, as a concession to reality, changing the phrase to "most common 10,000 passwords" with a footnote explaining that this will be enforced on a best-effort basis, without penalties other than a required password-change if a password is accepted but later falls into the top-10,000 as that list changes over time or as corrections are made to the list. davidwr/(talk)/(contribs) 14:49, 21 December 2015 (UTC)
I think it depends entirely on how this enforcement is going to be implemented. If the WMF are going to run a password cracker on all admin accounts and lock any that are crackable, I think it's a moot point that it's in the top 10, 1000 or 10,000. Until the password is corrected, the account won't be usable. Ritchie333 (talk) (cont) 15:00, 21 December 2015 (UTC)
My comment stands - the consensus number from the earlier discussion was around 10,000, so that is the number that should be used in any policy document and there should be a best-effort to use that number in the enforcement. If technical details mean we only enforce 10 or 1000 for the time being that shouldn't change the policy statement - privileged users should expect that enforcement of the top 10,000 passwords will begin as soon as the technical details are worked out, with little or no additional notice (although the reality is there will probably be days or weeks of notice). davidwr/(talk)/(contribs) 15:19, 21 December 2015 (UTC)

There's some discussion of these subjects on the talk page of the RFC, including input by WMF staffers. These lists already exist, at the meta RFC on this same subject WMF staff have indicated a preferred one, presumably that will be the one that applies here. At the moment, there is no auditing, but I believe the WMF folks have some idea of how they intend it to work and it doesn't appear to involve trying to crack passwords. In any event, we have a consensus, and as David points out arbitralily changing the results to something other than what the consensus determined doesn't seem right. Beeblebrox (talk) 19:19, 21 December 2015 (UTC)

I apologize if I'm missing something right in front of me, but is there a link to that RfC? Jonathunder (talk) 04:44, 22 December 2015 (UTC)
The meta RfC is here. The RfC's talk page shows a couple of thoughts about how passwords would be checked—the main point being that password restrictions would be checked each time that a user logs on, or when they attempt to change their password. In both those cases, no cracking of the password is required. Johnuniq (talk) 05:24, 22 December 2015 (UTC)
The meta RFC is certainly relevant, but I was actually referring to Wikipedia:Security review RfC, the discussion that led to this policy. Beeblebrox (talk) 00:32, 23 December 2015 (UTC)

"Passwords must be at least 8 bytes in length."

Could this please be expressed in terms of characters, too?  Sandstein  12:18, 22 December 2015 (UTC)

This is 8 characters for passwords using Latin letters, and I am pretty sure everybody who voted (including me) has in mind just 8 characters.--Ymblanter (talk) 20:43, 22 December 2015 (UTC)
Each letter and digit in the English alphabet is one byte, so 8 bytes is 8 characters using A–Z or a–z or 0–9. However, no simple statement can be made in general because, for example, an em dash (—) is three bytes in the UTF-8 encoding used by MediaWiki, and a single letter in many other languages occupies more than one byte. For example é is two bytes and the name ঢাকা (Dhaka) has two characters, each of which is six bytes. Johnuniq (talk) 23:30, 22 December 2015 (UTC)
How about adding a note or parenthesis stating that for the English alphabet this usually corresponds to 8 characters? Sam Walton (talk) 23:47, 22 December 2015 (UTC)
That sounds reasonable. Beeblebrox (talk) 00:29, 23 December 2015 (UTC)

Don't store password strength

As an implementation detail, it is very important we don't store the password strength in the database. Doing so provides a way of significantly speeding up a brute-force password attack if we ever leak the authentication database. See A Tale of Security Gone Wrong. That's not my blog and I'm not the author, but I'm happy to answer technical questions on this subject. It's incredibly unlikely that we would store the password strength in the database, I'm just covering our bases. --Yamla (talk) 19:23, 16 November 2016 (UTC)

Actually, you could store the strength with relatively little loss so long as you only stored a couple bits of information about it ["tank", "hiding behind low wall", "hiding behind car door", "tied up in the middle of the street with a shotgun taped to the back of his head"]. But yes, there's little point, and even that would make a hacker's life a bit easier. Wnt (talk) 21:25, 16 November 2016 (UTC)

RFC November 2016

NO CONSENSUS FOR CHANGE
There isn't consensus to implement this change. The primary objection is that it can't be enforced though there is wide agreement it is a very (very) good idea. Other options, including machine-generated passwords and two-factor identification have been proposed as solutions that would be enforceable and would be worth pursuing at the corporate level. Hobit (talk) 16:30, 23 December 2016 (UTC)

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.


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)
PerWP: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)
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. Stephen 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. Stephen 09:56, 17 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. –Davey2010Talk 02:30, 18 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)
Strong Wikipedia password securing an admin's bike
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've added a new section to address this and encourage others to make any improvements they can think of. Beeblebrox (talk) 19:43, 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)
@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. Monty845 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 (TALKCONT) 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)
@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)
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)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

10,000 most common passwords

I noticed that @^demon: took out the promise to provide a list of the 10,000 most common passwords [3] based on the idea that it increases vulnerability by letting hackers know which passwords not to try. I see some sense in that, but not much. It only matters in the case where an admin would have picked a different list of 10,000 passwords than one we hypothetically would supply, which contains a few entries that the one we would have doesn't, and one of those entries was his password... the odds seem very low. Whereas the odds that the admin will not bother to go out and do the busy work of finding his own list of passwords seem very high. So I added a link to a list that I believe to be CC-by-SA 3.0. [4] It is my intention, if this edit sticks, to actually copy the list to a Wikipedia: namespace page, so that editors can more conveniently flip to it and control-F their password. Wnt (talk) 00:54, 17 November 2016 (UTC)

Meh. I disagree with the utility of providing the list of passwords, considering ours may morph with time (there's talk of including some common non-English passwords as well) and keeping them up to date with a public on-wiki list probably won't happen with any sense of regularity. In the case of dictionary-based attacks, let's assume a hacker has a list of passwords that they know work elsewhere (eg: from a breach of SomeAwesomeWebsite). If they've got a list of passwords that they know won't work here, it allows them to shorten their list by 10,000 (or however many) passwords. I think not publishing it helps us more than publishing it helps the users hit by it. But...I'm not going to revert or stop you from posting a link to a random third party list that may or may not reflect reality ;-) ^demon[omg plz] 03:56, 17 November 2016 (UTC)
note, the list is not cc-by-sa (it is public domain). Just because one's password is not on the list doesnt mean its secure. If you even remotely believe your password could be on the list, its probably a horrible password. BWolff (WMF) (talk) 04:16, 17 November 2016 (UTC)
And to reiterate what demon said, we reserve the right to modify or expand that list without telling anyone. BWolff (WMF) (talk) 03:57, 22 November 2016 (UTC)

The 10k most common passwords isn't that useful. Brute force searches by real attackers try a lot more passwords than that. It's better for the server to assign a password (two random 6 or 7 letter words from a dictionary, separated by a hyphen, is a reasonable method: see diceware for the reasoning behind this). I'd counterpropose that the wiki software be modified to make server-assigned passwords mandatory strongly recommended for advanced permission holders, and available as an option for other users. On getting a sysop bit you'd be required to do a password change, and then you can do additional changes (to new server-assigned passwords) whenever you want. 50.0.136.56 (talk) 00:50, 18 November 2016 (UTC) (updated 09:22, 7 December 2016 (UTC))

To clarify, the original design goal of banning top 10k passwords was to make sure that an online brute force attack would stand out enough in the logs that somebody would notice. Not being on that list definitely does not mean your password is secure. I strongly encourage everyone to have passwords that are significantly more secure than not in 10k most popular. BWolff (WMF) (talk) 03:57, 22 November 2016 (UTC)
That's a good idea, but I'd hope there's automatic alerts for it, rather than waiting for someone to notice. 50.0.136.56 (talk) 08:49, 7 December 2016 (UTC)
Also, if the 10k (or 100k etc.) exclusion list becomes known, then the brute force attacker can just avoid trying those. I also don't see the 10k list helping much in these cases of password guesses coming out of a database breach on some other site, though noticing an uptick in the sitewide bad password rate could raise an alert. 50.0.136.56 (talk) 09:19, 7 December 2016 (UTC)

Password testing tools

A recent edit by Fastily added an external link:

The idea of checking a password is good, but we should never encourage people to enter their passwords into a page other than when logging on (and then, only when the user expects to be logging on!). If strength checking is desirable, it should be built into MediaWiki for use when a user enters their password to create their account or to log on. Johnuniq (talk) 10:12, 17 November 2016 (UTC)

My password (which was Password1) failed that test, so I have changed it (to Password2). I think I've now fooled the hackers. SilkTork ✔Tea time 10:19, 17 November 2016 (UTC)
Mediawiki has an automated system to obscure your actual password, so I see My password (which was Password1) failed that test, so I have changed it (to *********) (no not really - hunter2). That being said, the community decided that password audits for functionaries and administrators would be a good idea, so I'm working on a specific RfC to address the technical implementation. Thoughts for possible implementations would be appreciated at VPT -- samtar talk or stalk 11:14, 17 November 2016 (UTC)
@Johnuniq: There's a *huge* disclaimer at the top of the Kaspersky tool which warns users not to enter any of their real passwords. You didn't do that just now, did you? ;) I linked the tool because it's a great interactive resource which helps educate users about the importance of selecting a strong password. -FASTILY 19:39, 17 November 2016 (UTC)
I don't think anyone in the above conversion suggested that (I assume "Password2" is a facetious suggestion). However, there is a problem that the Kaspersky tool isn't really that informative unless you use it on the real password. The reason is that a few of the passwords on the list of 10,000 most common passwords are actually pretty random and secure-looking, so you can type out all but the last two letters and it tells you a home computer would take months to crack them, but then you finish the whole thing and it drops back down to seconds. You can't really test for that with a mock password - we need something like that tool as part of the password setting interface itself (the part of our site that is actually authorized to see what our users' password plaintexts are) in order to get the benefit. Wnt (talk) 21:12, 17 November 2016 (UTC)
This link should be removed, people are going to ignore that warning and start putting their passwords into a random third party site we don't control. 😖 ^demon[omg plz] 06:30, 18 November 2016 (UTC)
I went ahead and removed it. It was an unimpressive password meter anyway. I've always found password strength meters to be annoying and useless, but maybe that's just me. 50.0.136.56 (talk) 04:16, 19 November 2016 (UTC)
I should note (without commenting on the merits of that particular tool) that the security review RFC that prompted the original creation of this policy did authorize a password strength bar. Beeblebrox (talk) 22:52, 22 November 2016 (UTC)
It says the password "cats and dogs" would take 9 centuries - I find that hard to beleive. עוד מישהו Od Mishehu 18:45, 24 November 2016 (UTC)

Please indicate maximum length and available character set

While knowing that 8 chars is the minimum is a start, it would also be helpful to know what the maximum length and allowable character set is.

For those of us who use random password generators, these simple pieces of information can prevent having to try multiple passwords due to unstated length/character set limitations.

These limits should be stated on the page and also clearly displayed when a password does not meet the acceptance criteria.

SsteinerX (talk) 13:18, 8 May 2017 (UTC)

Reusing passwords

Is there a reason this page and WP:User account security do not appear to mention that passwords should never be reused from other websites? It's ok to have the same password for several "who cares" sites where the account does not contain personal details and does not matter. But the account name and password used at Wikipedia should not be the same as at any other website. That is because hundreds of websites have been hacked and anyone can download lists of account names and passwords that can be used to attempt logins at Wikipedia. At least two admin accounts were hacked in that way, fortunately by a white hat who reported the problem. Johnuniq (talk) 23:02, 5 January 2018 (UTC)

It is mentioned in the last section, but is not part of the actual requirements. (See the RFC further up the page, I tried.) Beeblebrox (talk) 03:01, 6 January 2018 (UTC)
Thanks, I'd forgotten about that RfC, and I missed the "your Wikipedia password should be unique" mention. Re the RfC, I guess people got sidetracked with the "Users found to be in breach of this policy..." text that you struck to minimize off-topic commentary. It is obvious to anyone familiar with security concepts that the Requirements section should include a third point to the effect that passwords should be unique. Johnuniq (talk) 03:45, 6 January 2018 (UTC)
I should mention that I responded at WT:User account security#Recent multiple failed attempts to log into account and wanted to find a page I could link to that clearly explained the problem. Johnuniq (talk) 06:12, 6 January 2018 (UTC)

password length

In light of current events, 8 bytes seems laughably too short.--Dlohcierekim (talk) 00:41, 5 May 2018 (UTC)

Why? We have approximately 80 symbols even if we do not use other alphabets; for 8 symbols length it is 80^8 which is roughly 10^15. Currently one can only try - how many? 10? passwords per minute, which means a vandal can break a secure 8-symbol password in 10^14 minutes which is still 10^8 years. Alternatively, they will need to set a million of parallel breaking-in accounts, then it only takes a hundred years. And if at some point quantum cryptography algorithms become available to wiki-vandals, there is not going to be much difference between eight and twenty symbols, we will all need to go to mandatory 2FA--Ymblanter (talk) 08:31, 5 May 2018 (UTC)
Almost no one uses characters randomly selected from 26 symbols, let alone 80. Johnuniq (talk) 09:09, 5 May 2018 (UTC)
A strong password requires numbers, special characters, and sometimes big and small letters to be present.--Ymblanter (talk) 09:11, 5 May 2018 (UTC)
Yes. However, there are nowhere near as many as 80^8 combinations in practice. Johnuniq (talk) 10:13, 5 May 2018 (UTC)
I do not know. As I have written elsewhere, my password is a fairly random combination, and I am not able to memorize it.--Ymblanter (talk) 11:13, 5 May 2018 (UTC)
Thanks, Ymblanter. I haven't used 8 byte passwords in years. I'm a little surprised at so many accounts on W falling so easily them. And I've gotten better at remembering them.--Dlohcierekim (talk) 15:29, 5 May 2018 (UTC)

During the security review that led to this policy being established, there was a lot of talk about length-vs-differing characters, and people who seemed to know a lot more than me about these matters argued that using random strings of numbers, letters, and symbols makes passwords difficult to remember, whereas using a phrase of random words provides something easier to remember but very difficult to guess/brute force. Four to six words should be a good password for anyone. Beeblebrox (talk) 18:57, 5 May 2018 (UTC)

Wait a tick-- I can use non-Latin alphabet letters? Way cool!--Dlohcierekim (talk) 19:12, 5 May 2018 (UTC)
Such are still susceptible to dictionary attacks, so you do need to go a bit more out of your way than just stringing a bunch of words together. --Izno (talk) 20:20, 5 May 2018 (UTC)
Retrieved from "https://wiki.riteme.site/w/index.php?title=Wikipedia_talk:Password_strength_requirements/Archive_1&oldid=1086032945"