Wikipedia:Security review RfC

On the 4 November 2015, two administrator accounts were compromised. It appears that both account had used passwords on Wikipedia and on other sites and one of the other sites had been breached. The highlighted security issue, however, makes this a good time to review our password requirements.

This RfC is to look at what levels of password protection we should require and for what usergroups. I intend to start a similar RfC on meta for global changes to the password policy in the near future. I've also asked the question about two-factor authentication.

Current position

• Passwords for all usergroups have the same requirements, but different requirements can be set differently per usergroup and per project. If a password requirement is set for a specific usergroup on a specific project, it will only be enforced if they log in on that project.
• Adding rules to passwords is very simple, and only requires community consensus to implement. We have a member of the WMF Security Team lined up who is willing to implement some changes for us, assuming we have that consensus.
• The only current requirement for a password is that it has a non-zero length and is not the same as the user's username.

Suggestions

Status quo

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.

---

We have the option to make no changes to the password system. If you do not agree with making any changes, please support here.

Support Status Quo

1. Yes -- the "status quo" requires persons to be cognizant of the problem - making arbitrary changes to requiring (say) 255 characters simply makes the apparent onus fall on the rule-makers, and not the fault of people who have not learned what folks on ISPs learned as a rule more than twenty years ago - do not use easy passwords on important stuff, and feel free to use easy passwords on totally unimportant stuff. Until we get folks who understand this, any changes are going to be a tad futile. Collect (talk) 19:51, 6 November 2015 (UTC)
2. Not entirely status quo - I'd go along with the concept of requiring a minimum bit-length and rejecting extremely common passwords such as "password" or "123456" the latter of which I already thought was in place for all accounts - but the key to resolving these periodic situations is to make it socially unacceptable to have an insecure password. And the key to that is to include in WP:ADMIN a statement that all administrators are expected to have passwords that (a) are not their username, real name, or email address (b) do not include a personally significant date, the name of a close associate, significant other or family member, or other term/word/name/phrase that could be associated with the user, and (c) is uniquely associated with the user's administrator account and has never been used elsewhere. If an account is breached, the user will be desysopped until he or she can show that the password did not fail any of these criteria. Administrators whose accounts are breached while using a password that does not pass all of the criteria will not be re-sysopped unless they successfully complete an RFA after the breach has been resolved.

   In other words, if you don't have a decent password, and you get pwned, you don't get your bits back. Given what we know now, I probably would not support having returned the bits to either of the two recently breached admin accounts without a further RFA. Risker (talk) 05:43, 7 November 2015 (UTC)

3. I support the status quo if the only alternative presented to me is the "solutions" proposed in this RfC. The thinking here seems to be as follows: Something must be done. This is something. Therefor this must be done --Guy Macon (talk) 19:52, 20 November 2015 (UTC)
4. passwords on WP are totally unimportant so there is no need to raise the limit. One might think otherwise for accounts with CU function, but as an admin I consider my WP password to be one of the most unimportant I use at all. Let's spend our time doing important stuff. --h-stt !? 14:21, 24 November 2015 (UTC)
5. Yes - No need for force password changes. As with any website, users need to realize the importance of using a secure password. Meatsgains (talk) 03:14, 29 November 2015 (UTC)
6. Support status quo for password system There can be changes to social systems to invite people to use stronger passwords but I would prefer to not compel users to do something against their wishes. Wikipedia is the most free site on the Internet and part of that freedom is granting choices which are available nowhere else. Having short or even one-character passwords is part of that choice and part of the prestige and attraction of Wikipedia. For some specialized users, including anyone with advanced permissions on a Wikimedia project, I would support compliance with heightened security to match the heightened responsibility that those userrights might grant. If there were to be heightened requirements, I would want changes to the Wikimedia social infrastructure, and not necessarily changes to Wikimedia's technical password system. At the same time, I would support more educational outreach from Wikimedia projects to the public generally about online safety. Anyone who is considering using technical barriers to force users to take certain actions might also support social or educational tools to guide people to make the choices we decide we want them to take. Perhaps if someone chooses a bad password we could have a nag message asking them to take another one, or if someone has not changed their password after some time they could get an alert to change it. A consensual and educational approach seems more in line with Wikimedia community values than making a hard change. I am not persuaded about a great risk to projects because of compromised accounts, except from people with advanced permissions. Without supporting technical password restrictions on everyone, I might support such a thing on admins and people with unusual tool access. Blue Rasberry (talk) 21:50, 2 December 2015 (UTC)

Oppose Status Quo

1. I believe that the status quo is not acceptable. Worm^TT(talk) 10:47, 5 November 2015 (UTC)
2. I agree. Callanecc (talk • contribs • logs) 11:18, 5 November 2015 (UTC)
3. Agreed. --Dweller (talk) 11:21, 5 November 2015 (UTC)
4. Sam Walton (talk) 12:06, 5 November 2015 (UTC)
5. The situation we recently experienced shows this does not appear to be a suitable option. Amortias (T)(C) 12:29, 5 November 2015 (UTC)
6. It's quite evident that the current password system has problems and needs to be improved. Elockid ^{Message me} 13:21, 5 November 2015 (UTC)
7. Strongly Oppose. After yesterday's incidents, we really need a password minimum length and a "password strength" checker, so people don't go around making all-numeric passwords. epic genius (talk) 14:04, 5 November 2015 (UTC)
8. Oppose Assuming the bare minimum (1 character) and 1 password a second, we're looking at less than 3 minutes to brute force. Hasteur (talk) 15:56, 5 November 2015 (UTC)
9. Too dangerous--Ymblanter (talk) 17:49, 5 November 2015 (UTC)
10. Agree with all above. BMK (talk) 18:29, 5 November 2015 (UTC)
11. BethNaught (talk) 19:24, 5 November 2015 (UTC)
12. The password should be longer than one byte. -- GB fan 19:52, 5 November 2015 (UTC)
13. Common sense and the recent experience show something is needed. Johnuniq (talk) 00:53, 6 November 2015 (UTC)
14. It isn't acceptable. If not better password requirements, we need 2FA. Lor^Talk 01:15, 6 November 2015 (UTC)
15. This is going to keep happening if we don't do something. — Earwig ^talk 09:03, 6 November 2015 (UTC)
16. — Ched :  ?  10:07, 6 November 2015 (UTC)
17. One byte? Seriously? MER-C 17:35, 6 November 2015 (UTC)
18. JohnCD (talk) 22:17, 6 November 2015 (UTC)
19. After that disaster we need to make the Passwords better otherwise this could happen again and again. –Davey2010^Talk 04:31, 10 November 2015 (UTC)
20. No, the status quo is entirely inadequate. ​—DoRD (talk)​ 01:10, 11 November 2015 (UTC)
21. Kudpung กุดผึ้ง (talk) 22:36, 15 November 2015 (UTC)
22. It is totally unacceptable to permit accounts with advance permissions to have a password consisting of only one byte. --Stefan2 (talk) 16:32, 16 November 2015 (UTC)
23. A higher minimum standard should be implemented, this is simply too low. DES ^(talk) 17:37, 17 November 2015 (UTC)
24. No. Zhaofeng Li [talk ♦ contribs] 13:29, 19 November 2015 (UTC)
25. Per above Status quo is not okay these days. ---- Patar knight - ^chat/_{contributions} 04:01, 20 November 2015 (UTC)
26. We need to set at least some realistic mimimum limits. jni ^(delete)_{...just not interested} 18:29, 26 November 2015 (UTC)
27. Chris Troutman (talk) 21:21, 5 December 2015 (UTC)

Discussion

Password requirements must be in "bits" not characters, because we are operating on MediaWiki software. Change the characters to bits or provide the rough equivalent please. Risker (talk) 11:35, 5 November 2015 (UTC)

Have changed to bits. IIRC, the first 255 characters in the relevant charmap are 1 bit long, and the current password length should be between 1 and 4096 bits. So, non latin characters may be longer than 1 bit, but I expect most characters English speakers would use are 1 bit long. Worm^TT(talk) 11:50, 5 November 2015 (UTC)

What definition of "bit" is being used here? Do you mean "byte"? 68.97.47.54 (talk) 13:12, 5 November 2015 (UTC)

Unless you mean Unicode characters? I think "UTF-8 characters" is meant. Someone can have a 8-byte Unicode character password with three or four characters. 8-bit (1-character) is the minimum used right now... epic genius (talk) 14:08, 5 November 2015 (UTC)

• I have changed it from bits to bytes, since that was what was intended, and what we are actually talking about.[1][2]. -- KTC (talk) 15:37, 5 November 2015 (UTC)

Sorry this is just nonsense. What we should really be discussing is "bits of entropy". For the purposes of this exercise "characters" is good enough. All the best: Rich Farmbrough, 20:03, 5 November 2015 (UTC).

Let me expand on this. 先生 is 6 bytes in UTF8, 48 bits. Yet it does not correspond to 6 ASCII characters (each being 7 bits of variety, but taking eight) but to a subset of the plane including the CJK characters which is 65536 characters in size, of which about half are CJK - so 15+15 = 30 bits.

So really all this talk of bits and bytes is (almost) completely unhelpful. There are really only two questions

1. What is the overlap area between acceptable difficulty for the user and acceptable security for that class of access, if any, and
2. What is the sweet-spot in that area.

In terms of information, the top 1,000,000 passwords have only about 20 bits of entropy. In other words choosing at random from these is 16 times weaker than a random 4 character ASCII password.

HTH. All the best: Rich Farmbrough, 14:01, 6 November 2015 (UTC).

Measuring bits of entropy in an arbitrary string is very difficult in practice. Ideally, yes we would measure the amount of entropy in the password. I have no idea how to do that though, (What is the distribution that we're assuming passwords are coming from? I guess you could take some password cracking algorithm, invert it, so you can map passwords -> what sequence number will it be guessed at. Not sure if one could do that efficiently). Bawolff (talk) 00:01, 24 November 2015 (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.

Length increase to 6 bytes

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 minimum length of a password should be increased from 1 byte to 6 bytes.

Support Length increase to 6 bytes

1. But prefer 8 bits. Worm^TT(talk) 10:47, 5 November 2015 (UTC)
2. Yep. Callanecc (talk • contribs • logs) 11:19, 5 November 2015 (UTC)
3. Support. POV alert, but this fits my ideas of common sense. --Dweller (talk) 11:22, 5 November 2015 (UTC)
4. At least this, but preferably 8 bytes. The longer the minimum, the better the password entropy. epic genius (talk) 14:04, 5 November 2015 (UTC)
5. At a minimum. --kelapstick^(bainuu) 17:25, 5 November 2015 (UTC)
6. Sounds reasonable--Ymblanter (talk) 17:49, 5 November 2015 (UTC)
7. Second choice to 8 bytes. BethNaught (talk) 19:24, 5 November 2015 (UTC)
8. At the very least. Six is definitely too short, but I'm not sure about eight. — Earwig ^talk 09:03, 6 November 2015 (UTC)

   Would you compromise on seven? All the best: Rich Farmbrough, 14:03, 6 November 2015 (UTC).
   

   Eh, eight seems fine the more I think about it. — Earwig ^talk 15:39, 6 November 2015 (UTC)

9. At a minimum. It's not going to be sufficient if you reuse a password with a site that gets breached and uses an obsolete hashing algorithm (MD5, SHA-1) -- brute force gives you as little as two hours (SHA-1) against someone with one GeForce Titan X. MER-C 17:44, 6 November 2015 (UTC)
10. Minimum. JohnCD (talk) 22:18, 6 November 2015 (UTC)
11. Okay. Risker (talk) 05:48, 7 November 2015 (UTC)
12. 6 or 8 seem reasonable. Mkdw^talk 22:26, 7 November 2015 (UTC)
13. Per above Second choice after 8 bytes. ---- Patar knight - ^chat/_{contributions} 04:01, 20 November 2015 (UTC)
14. Minimum acceptable standard, but 8 bytes would be better. jni ^(delete)_{...just not interested} 18:29, 26 November 2015 (UTC)

Oppose Length increase to 6 bytes

1. Far too short. Even with 95 base characters upper/lower alphnumeric +33 others, that's less than 10^12 combinations. --RexxS (talk) 03:00, 7 November 2015 (UTC)
2. Too small. This gives anyone with a CUDA-based password guesser the ability to do offline cracking, giving them instant access to any Wikipedia account that used a minimum-length password. --Guy Macon (talk) 19:52, 20 November 2015 (UTC)
3. Creates a false sense of security. For the purpose of a dictionary attack, 1 character is as good as 6 or 8. --Pgallert (talk) 18:23, 26 November 2015 (UTC)

   Its somewhat debatable how useful this is. Certainly, a 6 character password, is not very secure (and certainly, its very useless if someone uses a common password). But in the event of an online attack, it might help against a not all that dedicated attacker, or at least make the attack stand out enough in the server log to be noticed. Bawolff (talk) 00:32, 1 December 2015 (UTC)

4. Not usefully better than the status quo. LFaraone 04:28, 30 November 2015 (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.

Length increase to 8 bytes

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 minimum length of a password should be increased from 1 byte to 8 bytes.

Support Length increase to 8 bytes

1. For preference Worm^TT(talk) 10:47, 5 November 2015 (UTC)
2. Support While no password is truly uncrackable, the longer the password, the harder it is to crack KoshVorlon 11:46, 5 November 2015 (UTC)
3. Support. Basic security for almost any system I've ever used enforces a minimum length of at least 8. Amortias (T)(C) 12:29, 5 November 2015 (UTC)
4. As per my comments under "6-bits" [sic]. I think eight-byte-minimums are, at the very least, a little stronger password entropy. epic genius (talk) 14:04, 5 November 2015 (UTC)
5. The larger the solution space to test, the longer it would take for someone to try and break in. I consider 8 bytes to be the best compromise between users remembering and brute force attemp duration. Hasteur (talk) 15:58, 5 November 2015 (UTC)
6. Based on my totally unqualified guessing, it seems like the 7 to 8 is the watershed point, where it goes from relatively easy, to relatively difficult to crack. I would support this (without mandatory special character/number/capitals) for all editors, and encourage administrators to use more than 8. --kelapstick^(bainuu) 17:28, 5 November 2015 (UTC)
7. 8-10 chars is probably crackable from the hashes but this strikes a balance between memorisability and security. BethNaught (talk) 19:24, 5 November 2015 (UTC)
8. 8 bytes is too short to stop brute-force attempts on password dumps, while being too long to trivially memorize. It's a good compromise. --Carnildo (talk) 02:57, 6 November 2015 (UTC)
9. Pretty good requirement. APerson (talk!) 14:15, 6 November 2015 (UTC)
10. Looks like a basic and simple way to improve security. Rcsprinter¹²³ (sing) 14:32, 6 November 2015 (UTC)
11. This should be sufficient against someone with a bunch of GPUs even if someone uses the obsolete SHA-1. MER-C 17:50, 6 November 2015 (UTC)
12. Adequate. JohnCD (talk) 22:19, 6 November 2015 (UTC)
13. Okay. Risker (talk) 05:49, 7 November 2015 (UTC)
14. 6 or 8 seem reasonable. Mkdw^talk 22:26, 7 November 2015 (UTC)
15. yes, this is adequate and should not be a burden for any editor to make this amendment. Fylbecatulous talk 16:15, 8 November 2015 (UTC)
16. Unless everyone wants there account hacked then it's probably a good idea to make it longer & harder to guess... –Davey2010^Talk 04:38, 10 November 2015 (UTC)
17. This seems about right.- MrX 16:43, 11 November 2015 (UTC)
18. This is standard for most websites, in my admittedly limited experience. Mz7 (talk) 04:39, 14 November 2015 (UTC)
19. Support 8 bytes This is not an unreasonably high standard, and many web sites and online services require 8-byte passwords (or longer). While not long enough to make a brute-force attack impossible, it is long enough to make it non-trivial with current technology, and is short enough that few if any users will be discouraged. However, note that this would not have prevented the recent compromises. DES ^(talk) 17:42, 17 November 2015 (UTC)
20. Per above First choice before 6 bytes. ---- Patar knight - ^chat/_{contributions} 04:01, 20 November 2015 (UTC)
21. This strikes a good balance. Stifle (talk) 10:23, 23 November 2015 (UTC)
22. This is OK. NinjaRobotPirate (talk) 01:11, 25 November 2015 (UTC)
23. Yes, this is better than 6 bytes. jni ^(delete)_{...just not interested} 18:29, 26 November 2015 (UTC)
24. Sufficient enough to prevent breaches that aren't through simple password reuse, as long as other complexity requirements are made. LFaraone 04:29, 30 November 2015 (UTC)
25. Yes better, and reasonable enough. Yann (talk) 10:04, 30 November 2015 (UTC)
26. Chris Troutman (talk) 21:21, 5 December 2015 (UTC)

Oppose Length increase to 8 bytes

1. As the problems we have encountered to date are due to people's possibly complex passwords having been revealed elsewhere, I oppose all options that make passwords more proscriptive and awkward for users, except for at least a minimum standard of commonsense. --Dweller (talk) 11:27, 5 November 2015 (UTC)

   Disagree with precept. DoB is not a "complex password". All the best: Rich Farmbrough, 14:04, 6 November 2015 (UTC).
   

2. Far too short. Even with 95 base characters upper/lower alphnumeric +33 others, that's less than 10^16 combinations. --RexxS (talk) 03:01, 7 November 2015 (UTC)
3. Too small. This gives anyone with a CUDA-based password guesser the ability to do offline cracking,giving them access to any Wikipedia account that used a minimum-length password. Also, an RfC is the wrong answer here; technical problems with technical solutions should not be voted on by a collection of a few experts and a large number of non-experts. --Guy Macon (talk)
4. Creates a false sense of security. For the purpose of a dictionary attack, 1 character is as good as 6 or 8. --Pgallert (talk) 18:23, 26 November 2015 (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.

Length increase to 16 bytes

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 minimum length of a password should be increased from 1 byte to 16 bytes.

Support Length increase to 16 bytes

1. Per this. sst✈^discuss 13:44, 5 November 2015 (UTC)
2. Super High School Level Support In this day and age, why take chances? Is it really that hard for people to download say, KeePassX, and then have a random password of any length generated via a rather convenient GUI? I think not. The future must be considered. With ever expanding resources, malicious third parties are a force to be reckoned with. Again, why take chances? (For all the convenience arguments, look up KeePass) --DSA510 Pls No Bully 05:45, 6 November 2015 (UTC)
3. With just upper and lower case that's more than 10^27 combinations, which is adequate. Add in numbers and you have over 10^28. Incidentally, adding in 33 punctuation characters only improves that to 4 x 10^31 and makes it near impossible to remember. Password strength is far more sensitive to length of password that it is to the number of characters you pick from. https://xkcd.com/936/ --RexxS (talk) 03:10, 7 November 2015 (UTC)
4. I am assuming that, for instance, if "length increase to 16 bytes" and "impose restriction on admins" gain consensus [and "impose restriction on all users" doesn't], that this means that a 16 byte restriction will be applied to admins only. Given this, my support for this proposal is conditional on the minimum length increase only being applied to a specific user group (e.g. people with AWB rights, 'admins or higher'). This would render arguments below like "this may even deter some people from signing up" redundant. — Bilorv_(talk)^(c)(e) 17:41, 20 November 2015 (UTC)
5. This is an excellent way of making sure that someone does not pick a Wikipedia password that they are already using on other sites. Also, an RfC is the wrong answer here; complex technical problems with a variety of technical solutions should not be decided by having a small subset of the available solutions voted on by a collection of a few experts and a large number of non-experts. --Guy Macon (talk) 21:37, 20 November 2015 (UTC)
6. I don't think I'm special, and I can memorize a 16 character alphanumeric string. I guess it's academic, though, as this isn't going to pass. NinjaRobotPirate (talk) 01:25, 25 November 2015 (UTC)
7. Chris Troutman (talk) 21:21, 5 December 2015 (UTC)

Oppose Length increase to 16 bytes

1. Not many people will want to remember a 16-character password. This may even deter some people from signing up. epic genius (talk) 14:16, 5 November 2015 (UTC)
2. Strong oppose As the problems we have encountered to date are due to people's possibly complex passwords having been revealed elsewhere, I oppose all options that make passwords more proscriptive and awkward for users, except for at least a minimum standard of commonsense. --Dweller (talk) 14:19, 5 November 2015 (UTC)
3. I've yet to decide on 6 or 8 characters, but 16 is certainly overkill. Sam Walton (talk) 15:38, 5 November 2015 (UTC)
4. Overkill. Coming up with a secure password of this length would in itself deter sign-ups. BethNaught (talk) 19:24, 5 November 2015 (UTC)
5. No need for a password this long. -- GB fan 20:13, 5 November 2015 (UTC)
6. Overkill. Many users will resort to writing such PWs down in insecure places, or will use "easy to recall" and in many cases easier to crack PWs. May also deter sign-ups. No evidence that breaches were due to brute-force attacks, which is the only case this helps with. DES ^(talk) 01:31, 6 November 2015 (UTC)
7. Too long; will only be confusing for most people. Do any other websites require passwords this long? — Earwig ^talk 09:03, 6 November 2015 (UTC)
8. Too much. JohnCD (talk) 22:19, 6 November 2015 (UTC)
9. People won't remember their passwords. Mkdw^talk 22:21, 7 November 2015 (UTC)
10. Still too short!, Make it 87 that should do it. –Davey2010^Talk 04:40, 10 November 2015 (UTC)
11. Excessive long. We're not protecting the Crown jewels.- MrX 16:44, 11 November 2015 (UTC)
12. 16 is too long and would potentially deter users from signing up. Mz7 (talk) 04:38, 14 November 2015 (UTC)
13. The accounts mentioned in the heading were hacked due to usew of the password on other sites; the harder we make the passwords to remember, the more likely users are to make that mistake. עוד מישהו Od Mishehu 22:23, 15 November 2015 (UTC)
14. Per above Seems excessive. ---- Patar knight - ^chat/_{contributions} 04:01, 20 November 2015 (UTC)
15. Length is not entropy! Longer passwords don't automatically make better passwords. What is far more likely is that they will be written down. HighInBC 01:40, 22 November 2015 (UTC)
16. Oppose, people will either write passwords down, forget them, or add repeated characters to the end. Stifle (talk) 10:23, 23 November 2015 (UTC)
17. Nobody outside IT or mathematics can pick a non-trivial password of this size, and remember it without writing it down somewhere. --Pgallert (talk) 18:23, 26 November 2015 (UTC)

Comment

• Would support for functionaries, and maybe for admins.
  • Long passwords allow for more entropy and more memorability at the same time. For example "Casablancagumshoe" is 16 characters and easy to remember. Neither word appears in the top 10,000 from the Brown Corpus, so we can estimate the entropy as >log(2) 100,000,000 i.e., in excess of 50 million guesses would be required to find the password even if one knew that it consisted of 2 English words. This is acceptable for a front-door brute-force attack (but not for a scenario where the shasow password file falls into black-hat hands).

All the best: Rich Farmbrough, 14:16, 6 November 2015 (UTC).

• I think Rich Farmbrough has touched on an important point. While I'm slightly opposed on this proposal and for various reasons including it does carry some risks, I'm not sure if people quite appreciate the advantage of this proposal. The advantage for this isn't that in resistant brute forces against wikimedia. Realisticly even 6 characters is probably enough for that if wikimedia is remotely decent at resisting online brute force attempts. (Exceptionally common passwords would be an exception.)

  The primary advantage for this is actually related to what started this proposal namely password reuse across sites. While people reusing passwords isn't ideal, and those with advanced permissions shouldn't be, the reality is with so many different accounts (federated logins are reduced that but many still don't support that), and not everyone wanting or knowing how to use unique password management apps like KeePass, many are going to share their passwords for less important sites. (Sadly many also share them for important passwords like their main email or financial sites.)

  This can spell problems when a website you use is compromised but it isn't guaranteed. It depends on how stupid the website was, but also in some cases your password length. If the website was very stupid and didn't use a hash or used a hash which is instantly reversable no matter the length, then your SOL and some websites in breaches did do that.

  However if the website is a bit smarter and used a hash, and the hash is slightly slow to generate this is actually when bruteforcing and password length or actually complexity comes in to play. If you have a 6 character password and the hash is MD5, it's basically guaranteed your password will become known if someone cares enough. Often people just do the whole database up to a certain length and even 8 characters tends to come out at least for alphanumeric.

  If you have a 16 character random password, with a remotely decent hash there is basically zero chance anyone is going to find out your password from the hash anytime in the near future (unless someone discovered a major flaw in MD5 or perhaps if there is a major breakthrough in quatum computers). Even if your password is 16 characters made up of English words (unknown how many words), I think it'll still take way too long to bruteforce (although I can't be bothered working out the figures). If you narrow it down to e.g. 2 words, it may start to become possible again but it's complicated (presuming you aren't being targeted, the person has to decide what to test the database against, e.g. 2 words in a 100000 word dictionary lower case, it'll generally help if you e.g. use a mix of upper and lower case this doesn't have to be really complex e.g. the the 3rd letter is uppercase, etc).

  In other words brute forcing is actually a big factor, but it's not brute forcing against a website but against a database.

  Nil Einne (talk) 22:11, 12 November 2015 (UTC)

• Force admin pw change after 1 month (or 3 or 6, whatever). It's really weird to me that this obvious security measure is one that is not listed among those with their own sections above. The #1 way that passwords get compromised is that someone uses the same pw or one with an obvious pattern (like "sKid00sitename") at multiple sites, and enough time passes for someone who's gotten it to go around site after site trying it out until they get around to trying it here. That's a time-consuming process and is generally defeated by rotating passwords mandatorily on a fairly frequently basis. It doesn't matter how super-duper complex a password is if someone recycles it on 50 other sites, a factor we cannot control for other than by not give the same admin pw here a very long lifespan. There's no need for user passwords to expire like that; since anyone in the world can edit, it really doesn't matter much if someone gets into a regular editor's account, other than they can make that editor look like they lost their mind for a bit. But a compromise admin account and wreak a lot of havoc.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  20:57, 21 November 2015 (UTC)

• Microsoft: Changing Passwords Isn't Worth the Effort
• Password Expiration Considered Harmful
• Security Myths and Passwords
• Does expiring passwords really help security?
• So Long, And No Thanks for the Externalities: The Rational Rejection of Security Advice by Users
• Please do not change your password
• Why do we annoy our users?
• The Security of Modern Password Expiration: An Algorithmic Framework and Empirical Analysis

--Guy Macon (talk) 23:55, 21 November 2015 (UTC)

• Your "obvious" security measure is actually a very bad idea and goes against consensus among security professionals. Requiring periodic password changes has, at best, no impact to password security, but likely degrades it! Please read the links Guy Macon posted above. jni ^(delete)_{...just not interested} 18:35, 26 November 2015 (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.

Case requirements

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.

---

A password should require at least 1 uppercase and 1 lowercase letter.

Support Case requirements

1. I would support this requirement. Worm^TT(talk) 10:47, 5 November 2015 (UTC)
2. Support Where I work, it's a requirement that passwords have at least one uppercase and one symbol! KoshVorlon 11:47, 5 November 2015 (UTC)
3. Support though theyre should be some options. 3 out the 4 such as 1 lower 1 uper 1 number 1 symbol gives flexibility as you have no way of knowing which 3 have been chosen. Amortias (T)(C) 12:29, 5 November 2015 (UTC)
4. If it contains a lowercase Latin alphabet character, it should also contain an uppercase Latin alphabet character. And vice versa. That is enough, and avoids any potential language issues (although I think that is not a real issue when it comes to this English-speaking wiki). At this stage in the proceedings, the only thing being supported is to require admin accounts to have password at least 8 characters long, making password an acceptable password - which is plainly ridiculous. — This, that and the other (talk) 08:59, 6 November 2015 (UTC)
5. It's relatively easy to remember upper and lower case combinations, and increasing the number of characters to choose from 26 to 52 gives a useful increase in strength. For example, a 12 character password consisting of only lower case gives 10^17 combinations, while 12 upper/lower case characters provides 3 x 10^21 combinations. --RexxS (talk) 03:12, 7 November 2015 (UTC)
6. I agree, per the above comments. Sam.gov (talk) 21:48, 13 November 2015 (UTC)
7. Chris Troutman (talk) 21:21, 5 December 2015 (UTC)

Oppose Case requirements

1. I oppose this, and numerical and symbol for the same reason. Forcing a password to have these requirements makes it easier to crack because it reduces the possible set of passwords. That is, a brute force attack takes less effort if the target is known to contain one or more uppercase, lowercase, number and symbol. Therefore, I prefer a "minimum complexity" requirement which ensures the password is strong without forcing it to contain particular sets of symbols. QuiteUnusual (talk) 11:04, 5 November 2015 (UTC)
2. As the problems we have encountered to date are due to people's possibly complex passwords having been revealed elsewhere, I oppose all options that make passwords more proscriptive and awkward for users, except for at least a minimum standard of commonsense. --Dweller (talk) 11:27, 5 November 2015 (UTC)
3. You already know, this WTT, we discussed it yesterday off-wiki. Upper/lower case letters work only for passwords that are written in latin languages. This rule demands the use of latin characters in a password, which is not okay. There is also zero evidence that this makes people's passwords more secure. Risker (talk) 11:38, 5 November 2015 (UTC)

   I don't disagree, I'm putting forward all the suggestions which have been put forward by the WMF Security chap. That said, I'd support it, on the basis that forcing people to think about their password is a good thing. Worm^TT(talk) 11:43, 5 November 2015 (UTC)

   The list of "Unicode Characters in the 'Letter, Uppercase' Category" can be found at http://www.fileformat.info/info/unicode/category/Lu/list.htm - as well as Latin it includes (for example) Cyrillic and Cherokee (e.g. Ꮨ).

   However you are right that some scripts do not have the distinction. It is trivial to exempt these in a Posix environment :

   if (toupper (password) === tolower (password)) {continue;}

   though other checks would probably be war rented if one was going down this route.

   All the best: Rich Farmbrough, 20:17, 5 November 2015 (UTC).
   

4. well, yes, but not this- because of language.--Müdigkeit (talk) 11:56, 5 November 2015 (UTC)
5. Per the above reasons; length is more important than this. Sam Walton (talk) 12:07, 5 November 2015 (UTC)
6. Many users use non-latin passwords. Forcing different cases does not enhance security much anyway. sst✈^discuss 13:42, 5 November 2015 (UTC)
7. One uppercase and one lowercase != harder to crack. What if I had a password that was my username, plus or minus a single character? It would be unscrambled in 2 seconds flat. epic genius (talk) 14:17, 5 November 2015 (UTC)
8. I can easily remember a 16-character password, in fact I don't even have to remember it, if it consists of the first letters of the words in a ≈16-word sentence that means something to me. Say a quote — not the opening lines of Pride and Prejudice but something obscure that's meaningful to me personally — something I already know by heart. That's easy. Remembering a nerds' delight of caps and symbols and numericals is hard even if it's short. Do I have to put this argument in five or six places below, too? Sorry, Worm, it's a good idea to collect opinions on this issue, but the way it's set up, and split up, is a bit of a nerds' delight in itself. I'd rather not bore everybody with versions of my suggestion all over the page. I support a 16-bit requirement for administrators. Bishonen | talk 15:57, 5 November 2015 (UTC).

   That'll be my brain in play... it's how it made sense to me - unfortunately! Worm^TT(talk) 16:03, 5 November 2015 (UTC)

9. This is not been shown to be an effective deterrent and can make passwords more difficult to remember. Beeblebrox (talk) 18:50, 5 November 2015 (UTC)
10. Passwords do not need character type requirements to be secure: see Diceware. BethNaught (talk) 19:24, 5 November 2015 (UTC)
11. See my answer below. But this has a worse effect. All the best: Rich Farmbrough, 20:05, 5 November 2015 (UTC).
    
12. The main purpose of this is to block PWS susceptible to dictionary attacks. It is not a bad idea for systems where PWs are always entered in the Latin charset. (a 3 out of 4 types as mentioned above is better). But a complexity test is much better, and can apply to unicode passwords. — Preceding unsigned comment added by DESiegel (talk • contribs) 01:33, 6 November 2015 (UTC)
13. Case requirements have always struck me as a bad idea, because they place limits on the sets of characters used for passwords. Less available characters are always more open to brute force attacks. See Rich's analysis below.--Jayron32 01:47, 6 November 2015 (UTC)
14. This makes passwords harder to memorize, without making them any more secure. If you require a capital letter, it's a virtual certainty that that letter will be the first one. --Carnildo (talk) 02:37, 6 November 2015 (UTC)
15. Oppose specific requirements like this one, since it does not add true security and only inconveniences users. Others have explained above in better detail. — Earwig ^talk 09:03, 6 November 2015 (UTC)
16. Per above. JohnCD (talk) 22:21, 6 November 2015 (UTC)
17. No. Opposition based on that this has not been shown to be effective. Agree also that this adds inconveniences to user. That dratted caps lock... Fylbecatulous talk 16:11, 8 November 2015 (UTC)
18. I already use an uppercase and lowercase and even a full stop but I guess having it as an official thing could perhaps inconvience alot of people and if there's no security benefits then it's kinda pointless. –Davey2010^Talk 04:45, 10 November 2015 (UTC)
19. Let users choose whatever case they prefer and use a variety of methods of strengthening their password as see fit.- MrX 16:47, 11 November 2015 (UTC)
20. Oppose - This adds significant inconvenience to the user, while not making it any easierharder to crack the account. עוד מישהו Od Mishehu 22:25, 15 November 2015 (UTC)
21. Per above Seems too arbitrary. Many fine passwords without this. ---- Patar knight - ^chat/_{contributions} 04:01, 20 November 2015 (UTC)
22. The password "Password" is incredibly insecure. The password "mypasswordistoolongtobruteforce" is very secure [or would be if I hadn't written it here]. Forcing people to use mixed case letters—or realistically, a single uppercase letter at the start of the password—helps very little. — Bilorv_(talk)^(c)(e) 17:41, 20 November 2015 (UTC)
23. Wrong answer to the problem. --Guy Macon (talk) 21:42, 20 November 2015 (UTC)
24. Not useful. Everyone will just put the first character of the password in uppercase. Stifle (talk) 10:24, 23 November 2015 (UTC)
25. Oppose Prevents "correct horse battery staple" jni ^(delete)_{...just not interested} 18:29, 26 November 2015 (UTC)

Comments

• @QuiteUnusual:; whilst requiring 1 or more of a certain character does reduce the overall password set, the intention of such a rule is to ensure that *all* passwords are within the largest set possible. Given that most people tend to use the quickest possible solution, you'll find that most people are in a much more reduced set (as in; lower case characters of 4-9 letters) which leaves them at risk. This sort of policy increases the overall average entropy of the entire password pool. Or in another way; it raises minimum-entropy value of the password set. At the same time it excludes only low-entropy sets (e.g. all lower or all upper case) so the maximum-entropy value passwords are unaffected. The overall result is to force an increase in the median/mean entropy of the password pool. It's one of the most effective ways of improving average password complexity. --Errant ^(chat!) 10:45, 9 November 2015 (UTC)
• @Od Mishehu: I think you mean "... while not making it any harder to crack the account", but anyway, that's demonstrably untrue: "correct horse battery STAP" is in a set that is 72 million times larger than the obvious set that contains "correct horse battery stap", and I just don't accept that it is any more difficult to remember. --RexxS (talk) 15:50, 16 November 2015 (UTC)
  • I didn't say that my opposition here is about ease of memory; I said that it's about the inconvenience - even on a desktop computer, this would be somewhat inconvenient, and certainly on many mobile devices where it would mean switching keyboards. And users would tend to group the upper and lower case letters, making the likely group of passwords significantly smaller. עוד מישהו Od Mishehu 21:28, 16 November 2015 (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.

Numerical requirements

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.

---

A password should require at least one numerical character - i.e. 0-9

Support Numerical requirements

1. I would support this requirement. Worm^TT(talk) 10:47, 5 November 2015 (UTC)
2. Support per the statement I made above KoshVorlon 11:48, 5 November 2015 (UTC)
3. Support though theyre should be some options. 3 out the 4 such as 1 lower 1 uper 1 number 1 symbol gives flexibility as you have no way of knowing which 3 have been chosen. Amortias (T)(C) 12:29, 5 November 2015 (UTC)
4. Atleast to me it's common sense to have a number on the end anyway..... –Davey2010^Talk 04:50, 10 November 2015 (UTC)
5. I would go for this as well. Sam.gov (talk) 21:55, 19 November 2015 (UTC)
6. Chris Troutman (talk) 21:21, 5 December 2015 (UTC)

Oppose Numerical requirements

1. As the problems we have encountered to date are due to people's possibly complex passwords having been revealed elsewhere, I oppose all options that make passwords more proscriptive and awkward for users, except for at least a minimum standard of commonsense. --Dweller (talk) 11:27, 5 November 2015 (UTC)
2. Not effective. sst✈^discuss 13:48, 5 November 2015 (UTC)
3. Also not effective, per the above. If I had a password that was my birth date ("Feb 25 1998", for example), it would be very easy to crack. epic genius (talk) 14:19, 5 November 2015 (UTC)
4. I agree, this is not an effective deterrent. Beeblebrox (talk) 18:51, 5 November 2015 (UTC)
5. Passwords do not need character type requirements to be secure: see Diceware. BethNaught (talk) 19:24, 5 November 2015 (UTC)
6. Oppose

Length =>	1	2	3	4	5	6	7	8
A-Z or a-z	26	676	17,576	456,976	11,881,376	308,915,776	8,031,810,176	208,827,064,576
A-Z and 0-9	36	1,296	46,656	1,679,616	60,466,176	2,176,782,336	78,364,164,096	2,821,109,907,456
A-Z and a-z	52	2,704	140,608	7,311,616	380,204,032	19,770,609,664	1,028,071,702,528	53,459,728,531,456
A-Z ,a-z and 0-9	62	3,844	238,328	14,776,336	916,132,832	56,800,235,584	3,521,614,606,208	218,340,105,584,896
Ditto but must have one digit	10	1,140	97,720	7,464,720	535,928,800	37,029,625,920	2,493,542,903,680	164,880,377,053,440

Thus imposing this requirement reduces the number of possibilities substantially. It does not rule out "11111AAAAA".

All the best: Rich Farmbrough, 19:33, 5 November 2015 (UTC).

7. Oppose per Rich. Limits on available characters always makes hacking easier, not harder. Once you've defined parameters more strictly, you've limited the available choices, and made cracking easier, not harder. --Jayron32 01:49, 6 November 2015 (UTC)
8. Oppose: In practice, this makes passwords less secure. Just as a required capital letter will be the first one in the password, a required number will be the last one -- and that digit takes the place of a more-secure letter. --Carnildo (talk) 02:39, 6 November 2015 (UTC)
9. Oppose per above section. — Earwig ^talk 09:03, 6 November 2015 (UTC)
10. Oppose per above. JohnCD (talk) 22:22, 6 November 2015 (UTC)
11. What Rich said.. Risker (talk) 05:50, 7 November 2015 (UTC)
12. Not especially effective. Let users choose whatever characters they prefer and use a variety of methods of hardening their password.- MrX 16:50, 11 November 2015 (UTC)
13. Per above Seems too arbitrary. Many fine passwords without this. ---- Patar knight - ^chat/_{contributions} 04:01, 20 November 2015 (UTC)
14. The password "password1" is incredibly insecure. The password "mypasswordistoolongtobruteforce" is very secure [or would be if I hadn't written it here]. Forcing people to use a number helps very little. — Bilorv_(talk)^(c)(e) 17:41, 20 November 2015 (UTC)
15. Wrong answer to the problem, popular among those who do not understand the math. --Guy Macon (talk) 21:44, 20 November 2015 (UTC)
16. Oppose. People will simply append 1 to the end of the password. Stifle (talk) 10:24, 23 November 2015 (UTC)
17. Oppose Prevents "correct horse battery staple" jni ^(delete)_{...just not interested} 18:29, 26 November 2015 (UTC)
18. Oppose Reduces the number of available passwords while making them hard to remember. The set of words, quotes or other letter strings that can be meaningful to a person is huge. The number of numbers that will be will be much smaller and probably quite crackable (I would expect a lot of dates which anyone can pull off Facebook). Happy Squirrel (talk) 20:34, 3 December 2015 (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.

Symbol requirements

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.

---

A password should require at least one symbol.

Support Symbol requirements

1. I would support this requirement Worm^TT(talk) 10:47, 5 November 2015 (UTC)
2. Support BUT be careful, as Wikipedia uses a SQL database, certain symbols and SQL just don't go together (won't share, per WP:BEANS), so IF we do all them, make sure there's text saying which symbols cannot be used as well. KoshVorlon 11:49, 5 November 2015 (UTC)

   I sincerely hope that passwords are stored encrypted, so this shouldn't be a problem. Will check though. Worm^TT(talk) 11:53, 5 November 2015 (UTC)

   Hashed (don't mean to be pedantic, but in this discussion such distinctions are important). And they are, so this is not a concern. — Earwig ^talk 16:32, 5 November 2015 (UTC)

   Indeed it may still be a concern, depending on how the password is handled before it is hashed. For example a test against a dictionary might be standard, which means that string still needs cleaning, or at least careful handling. All the best: Rich Farmbrough, 19:39, 5 November 2015 (UTC).
   

   This is not a concern (Im stating this as a developer). In addition to the password being hashed, we also properly escape all sql queries. You should feel free to use any valid unicode character in your password (overly pendantic note: except maybe non-whitespace ascii control characters, as MW doesnt let those be input in general. Also, Everything gets converted to NFC, so if you use a non-NFC passsword it will get converted to NFC). BWolff (WMF) (talk) 22:20, 15 November 2015 (UTC)

3. Support though theyre should be some options. 3 out the 4 such as 1 lower 1 uper 1 number 1 symbol gives flexibility as you have no way of knowing which 3 have been chosen. Amortias (T)(C) 12:29, 5 November 2015 (UTC)
4. Chris Troutman (talk) 21:21, 5 December 2015 (UTC)

Oppose Symbol requirements

1. As the problems we have encountered to date are due to people's possibly complex passwords having been revealed elsewhere, I oppose all options that make passwords more proscriptive and awkward for users, except for at least a minimum standard of commonsense. --Dweller (talk) 11:27, 5 November 2015 (UTC)
2. Symbols become seriously problematic when trying to log in from non-desktop situations, and there is no evidence that any of the password cracking situations we have seen to date would have been changed by this requirement. 13:09, 5 November 2015 (UTC) — Preceding unsigned comment added by Risker (talk • contribs)
3. Per Risker. sst✈^discuss 13:50, 5 November 2015 (UTC)
4. Not going to help unless you want editors to only edit on tablets and computers, or unless you have uppercase, numeral, AND symbol requirement. epic genius (talk) 14:20, 5 November 2015 (UTC)
5. Again, not an effective deterrent. Beeblebrox (talk) 18:52, 5 November 2015 (UTC)
6. Passwords do not need character type requirements to be secure: see Diceware. BethNaught (talk) 19:24, 5 November 2015 (UTC)
7. Oppose per Rich in section above. Forcing certain characters places limiting parameters on passwords, and makes them easier to hack. --Jayron32 01:50, 6 November 2015 (UTC)
8. Oppose: Just like a required digit makes passwords less secure, a required symbol does as well, only more so: the symbol usually comes from one of "!@#$%^&*", and like a required digit, is the last character of the password. --Carnildo (talk) 02:41, 6 November 2015 (UTC)
9. Oppose this one especially. — Earwig ^talk 09:03, 6 November 2015 (UTC)
10. Oppose per above. JohnCD (talk) 22:23, 6 November 2015 (UTC)
11. This makes remembering a password so much more difficult for a small increase in strength. An 11-character [alphanumeric+punctuation] password is no stronger than a 12-character alphanumeric one, and 186 times weaker than a 13-character purely alphabetic one. Length >> complexity. --RexxS (talk) 03:25, 7 November 2015 (UTC)
12. I too oppose this one especially. Per all above. Fylbecatulous talk 16:23, 8 November 2015 (UTC)
13. .... This would never work as to find a symbol would take forever for a start, All's it would lead to is a very sharp decline in editing here. –Davey2010^Talk 04:52, 10 November 2015 (UTC)
14. Not especially effective. Let users choose whatever characters they prefer and use a variety of methods of hardening their password.- MrX 16:52, 11 November 2015 (UTC)
15. Per above Seems too arbitrary. Many fine passwords without this. ---- Patar knight - ^chat/_{contributions} 04:01, 20 November 2015 (UTC)
16. The password "password." is incredibly insecure. The password "mypasswordistoolongtobruteforce" is very secure [or would be if I hadn't written it here]. Forcing people to use a symbol helps very little. — Bilorv_(talk)^(c)(e) 17:41, 20 November 2015 (UTC)
17. Wrong answer to the problem, makes passwords a lot harder to remember. Longer passwords are far more secure than shorter passwords with symbols.
18. Oppose Prevents "correct horse battery staple" jni ^(delete)_{...just not interested} 18:29, 26 November 2015 (UTC)
19. Oppose Just as in the required digit case, but even worse. Some really nonsensical string of uncommon words (or string of first letters from a quote) is probably the best password. You have tons of choices. Now force me to punctuate it. You then have to either be a natural at memorizing punctuation, or pick some kind of string with natural punctuation. The later vastly reduces the number of available strings. Happy Squirrel (talk) 20:40, 3 December 2015 (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.

Uncommon passwords

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.

---

A password should not be in the list of the 10,000 most common passwords.

Support Uncommon passwords

1. I would support this requirement. Worm^TT(talk) 10:47, 5 November 2015 (UTC)
2. This is a cheap way of preventing dictionary attacks. --Carnildo (talk) 02:43, 6 November 2015 (UTC)
3. Not necessarily 10,000, but some restriction for the absolutely most common passwords does not seem like a bad idea. Things like "12456" and "qwerty": strings someone could guess on a whim. — Earwig ^talk 09:03, 6 November 2015 (UTC)
4. Sounds like a good idea. APerson (talk!) 14:17, 6 November 2015 (UTC)
5. Useful, but not necessary. Using four items from the list of 10,000 most common passwords gives 10^16 combinations against a dictionary attack - still better than 8 characters taken from the set of alphanumeric + punctuation. --RexxS (talk) 03:31, 7 November 2015 (UTC)
6. Definitely. I would also like for the system to disallow single dictionary words as passwords.- MrX 16:53, 11 November 2015 (UTC)
7. Support, provided we make a list of these most common passwords in alphabetical order. עוד מישהו Od Mishehu 22:27, 15 November 2015 (UTC)
8. Support. Indeed I would support also "Password must not be a dictionary word." DES ^(talk) 17:51, 17 November 2015 (UTC)
9. Per above Seems sensible, though 10, 000 might be a bit much. ---- Patar knight - ^chat/_{contributions} 04:01, 20 November 2015 (UTC)
10. Support, but 10,000 is too small a number. Also, an RfC is the wrong answer here; complex technical problems with a variety of technical solutions should not be decided by having a small subset of the available solutions voted on by a collection of a few experts and a large number of non-experts. --Guy Macon (talk) 21:50, 20 November 2015 (UTC)
11. Support any trivial to guess password should not be allowed. HighInBC 01:42, 22 November 2015 (UTC)
12. Support, that seems sensible. Stifle (talk) 10:28, 23 November 2015 (UTC)
13. Support Reasonable. Yann (talk) 10:11, 30 November 2015 (UTC)
14. Chris Troutman (talk) 21:21, 5 December 2015 (UTC)

Oppose Uncommon passwords

1. I'm tentatively here, I think 10,000 is probably overkill. Callanecc (talk • contribs • logs) 11:18, 5 November 2015 (UTC)
2. Such a list of passwords would have to be from a website that is not Wikipedia. Who gets to decide which website to choose? sst✈^discuss 13:49, 5 November 2015 (UTC)
3. Tentative oppose unless WMF is willing to maintain a list of 10,000 most common passwords. In theory, this is a good idea, but in practice, if someone wants to create a weak password on purpose, let them do it. epic genius (talk) 14:21, 5 November 2015 (UTC)

   The WMF would be the ones who hold the list of 10,000 passwords. I expect they will keep them up to date from whatever source they'd get them from. Worm^TT(talk) 08:38, 6 November 2015 (UTC)

4. Commonsense should apply .... If someone wants to create a password like "Banana1" then they should knock themselves out,,,, literally!. –Davey2010^Talk 04:56, 10 November 2015 (UTC)

Comment Uncommon passwords

• Who on earth decides what the 10,000 most common passwords are? --Dweller (talk) 11:28, 5 November 2015 (UTC)

  I guess there would be a list somewhere of common passwords which are any new password is checked against. The 10,000 figure was suggested by the WMF Security chap, we could always reduce the number. I think the point is that common passwords are rejected. Worm^TT(talk) 11:33, 5 November 2015 (UTC)

  I've seen these published and used them at work. Typically they contain the obvious (like "qwerty", "password"), profanities, phrases like "Starwars", standard sequences like 12345 or abcde, repeating characters and others. I don't know how these lists were generated though. QuiteUnusual (talk) 11:44, 5 November 2015 (UTC)

  These lists are generated by a number of means, the most common is brute-forcing large password files that have been hacked and published on t' Internet. All the best: Rich Farmbrough, 20:26, 5 November 2015 (UTC).
  

  These common password lists are generally maintained by the people who do a lot of the actual password cracking in the first place. There are some common lists available and each individual cracker also has their own personalized list. They are based off of what passwords have been found in the past with high frequency (hence why there will be some various based on the particular cracker doing the work). Basically, any password on these lists won't last much more than a minute against a real world cracker as they are among the first things tested. In fact almost all of the phases of password cracking make use of these lists(lots of passes that add common prefix/suffix to the list as well). By taking one of the lists and prohibiting people from using any PW on the list, the overall security goes up substantially. Aaronspink (talk) 02:59, 6 November 2015 (UTC)

  For reference, one potential list https://github.com/danielmiessler/SecLists/blob/master/Passwords/10_million_password_list_top_10000.txt?raw=true . Bawolff (talk) 23:45, 23 November 2015 (UTC)

• I would rather see this kind of list first as I think that 10,000 might be a few too many. I could definitely support not using some number of the most common passwords though. Sam Walton (talk) 12:08, 5 November 2015 (UTC)

  There is risk of an attack that could give an attacker large number of log-in attempts, in the nature of several thousand up to hundreds of thousands, depending on how proactive the Foundation is. Statistically 10,000 isn't that great in htis context (birthday paradox).

  All the best: Rich Farmbrough, 20:26, 5 November 2015 (UTC).
  

  10,000 is very small (If there exists a list somewhere with your password on it, your password is probably too simple). However. I don't think the birthday paradox is relavent to the matter at hand (Passwords aren't chosen uniformly from some set, so probability of a collision is worse than what the birthday paradox would suggest, but collisions don't matter in terms of chosing a password (as far as i can tell)). Bawolff (talk) 23:52, 23 November 2015 (UTC)

• Here is a link I found that discusses common passwords and where the 10,000 number come from. -- GB fan 20:31, 5 November 2015 (UTC)
• How about just banning any password that has all numbers and is 8 characters or below? That oughta remove the birthday paradox problem. epic genius (talk) 00:50, 6 November 2015 (UTC)
• A 10,000-password list is actually quite small. For comparison, the default wordlist for Linux's "cracklib" security module has 1.6 million entries. --Carnildo (talk) 03:21, 6 November 2015 (UTC)
• Okay with this, but to be honest it should be applicable to *all* passwords on account creation and reset, regardless of access level, on top of being required if access level changes to a higher level. Risker (talk) 05:52, 7 November 2015 (UTC)
• This has been implemented and merged into MediaWiki. A configuration change is necessary for deployment. MER-C 21:42, 4 December 2015 (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.

Complexity requirement

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.

---

To ensure that the strength of the password is sufficent to resist a persistent brute force attack, those users who are subject to heightened password scrutiny will be required to devise a password of sufficent strength to resist attack for no less than 7 days. The WMF foundation will run an estimate on the relative strength of the password and evaluate it against the time it would take to brute force the password.

Support Complexity requirement

1. Putting this proposal down so it's descriptive and doesn't lay down exactly what requirements you must be between X and y characters long, what casing/special cahracters/numbers/etc. are in it. Hasteur (talk) 16:10, 5 November 2015 (UTC)
2. Tentative support depending on implementation details. DES ^(talk) 01:37, 6 November 2015 (UTC)
3. It is perfectly possible to create strong passwords that are easily remembered. The well-known xkcd version of "correct horse battery staple" is now considered a little weak with only about 44 bits of entropy (around 2 x 10^13 combinations). My current preference is to use a short sentence that contains numbers and a proper name like "9 out of 10 editors mock Jimbo." That's 30 characters, but who could forget it? and does anybody seriously think that even with pattern-matching and dictionary strategies, that's weaker than any of the impossible-to-remember suggestions we have in the discussion above? --RexxS (talk) 03:47, 7 November 2015 (UTC)
4. This a good concept that I've seen used in other systems. As a user attempts to choose a password, the system assigns a score. A minimum score would have to be achieved for the password to be accepted. It's also a great way for users to learn how to choose secure passwords.- MrX 16:57, 11 November 2015 (UTC)
5. Support, but the devil is in the details. The strength checker needs to say that "nine out of ten wikipedia editors love jimbo" is strong, "Wikipedia; The Free Encyclopedia That Anyone Can Edit" is weak, "btulvkzhrrmnjgcmqeae" is strong and "6Kx4#Nf!" is weak. --Guy Macon (talk) 22:09, 20 November 2015 (UTC)

Oppose Complexity requirement

1. This is impossible to enforce. For any definition of "strength" beyond "is it on any list of common passwords", the strength is simply a wild guess, based on the assumption that an attacker is using the same set of password-generation patterns that the strength checker is. --Carnildo (talk) 02:47, 6 November 2015 (UTC)
2. Has no bearing on the reality of how almost all passwords are compromised in almost all settings: repeated use of the same password over multiple sites or accounts, selecting passwords that could well meet the complexity requirements but can be deduced if someone knows a little bit about the account holder, and not being cautious about keeping one's password secure. Every known abuse of an admin (or higher) account has been because of one of these issues, not because one's password wasn't complex enough, and that's the situation for almost all hacked accounts on almost all sites. Seriously, people. Admin accounts are easily blocked. And we're not talking nuclear launch codes here, we're talking about a website that's widely known to be vandalized thousands of times per hour. Risker (talk) 05:21, 7 November 2015 (UTC)

   Well, actually it does. By not stating the method of choosing candidate attack passwords these issues are elided. But obvious (and well published) methods, all known compromised passwords (from every account on every system) are tried, and all terms relating to the user. This second part so well established that a filk song was written about it back in the 70s or 80s

   Try his first wife's maiden name,

   This is more than just a game,

   It's real fun, but just the same,

   It's hacking, hacking, hacking.

   All the best: Rich Farmbrough, 14:24, 7 November 2015 (UTC).
   

   Rich, could you reformat the above so that it doesn't reset the !vote count to 1? Thanks! --Guy Macon (talk) 22:09, 20 November 2015 (UTC)

   Maybe that's part of the hack! All the best: Rich Farmbrough, 22:30, 20 November 2015 (UTC).
   

3. How on earth am I supposed to figure out if my password meets this rule? עוד מישהו Od Mishehu 22:28, 15 November 2015 (UTC)
4. Per above Seems inferior to a "relative strength" password advice bar when creating passwords. ---- Patar knight - ^chat/_{contributions} 04:01, 20 November 2015 (UTC)
5. Estimating the complexity of a password is far from accurate. Also I am not showing my password to anyone. HighInBC 01:43, 22 November 2015 (UTC)

Comment Complexity requirement

• How does the WMF estimate the relative strength of a password without either trying to crack it or having you tell it to them? — Earwig ^talk 16:37, 5 November 2015 (UTC)
  • @The Earwig: Prior to hashing the password down to what gets stored in the database, WMF hands the password over to a standardized library to evaluate the strength of the password (i.e. the entropy in it). Anything below a certain threshold that WMF establishes for users that have a higher scrutiny gets rejected for the user to retry. The password is available prior to the hashing in cleartext so WMF can run the estimate on it. Yes this means changing your password will take a little longer but ensures we get higher quality passwords (as defined by the entropy in them) without resorting to arbitrary rules. Hasteur (talk) 16:46, 5 November 2015 (UTC)
  • There are library routines, if I am not mistaken, which can perform such a check on the fly, and approve or disapprove as a user enters the PW. Using one seems like a good idea. — Preceding unsigned comment added by DESiegel (talk • contribs) 01:37, 6 November 2015 (UTC)
• What hardware budget and hashing algorithm will be used for this comparison? MER-C 17:41, 14 November 2015 (UTC)
  • MER-C I would estimate that the comparison should be no more than $200 for an enterprise level library estimate (or it could be replaced by a Free, Libre, Open Source Software (F-OSS) library as well), but at the same time it only kicks in when the restricted user is choosing a new password. The hashing down is already done (because wikipedia doesn't store the cleartext passwords in the database). Hasteur (talk) 16:51, 16 November 2015 (UTC)
    • I was referring to the requirement about "resist[ing] attack for no less than 7 days" -- i.e. how much the theoretical adversary is willing to spend on GPUs, FPGAs or ASICs to speed up the attack. Are we talking backyard (someone with a Titan X or two = $1000 each), cybercrime gang (~$100k), nation state (millions) or NSA type resources? The ability to crack scales linearly with budget, but shrinks exponentially with complexity. I also found out MediaWiki uses SHA-256 ... not the best algorithm for password hashing, but secure for now. MER-C 17:07, 16 November 2015 (UTC)
      • In that question I would say somewhere in the range of a cybercrime gang. Keeping in mind that most of the delay is going to be sending the password attempt over (with the login) to see if it works. I would estimate ~0.5 seconds as a best case scenario for a single attempt. A home hobbyist isn't going to be brute forcing an admin's password. If a nation state starts pushing on the door, they're going to get in (unless they already have moles planted). We may also want the foundation to explain how many bad attempts triggers a timeout on attempting more passwords. Hasteur (talk) 17:24, 16 November 2015 (UTC)
        • Cybercrime gang is probably about right. There is some real money available for anyone who can sneak advertising unto Wikipedia undetected, and some might see compromising the accounts of an admin of even a WMF staffer as a way to accomplish that. It wouldn't work, of course, but we can't count on the cybercriminal figuring that out until he tries it a few times. --Guy Macon (talk) 00:09, 22 November 2015 (UTC)
          • If bad attempts cause a timeout on attempting more passwords, then anyone who is willing to run a script 24/7 on their home PC will be able to lock out anyone on Wikipedia who annoys them. --Guy Macon (talk) 00:14, 22 November 2015 (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.

Add a password strength bar to the "Create account" page

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.

---

This is self-explanatory and easy to make. Such examples include this or this. This "password strength bar" would be placed above, below, or next to the input boxes for "Enter your password." It would be just a recommendation (this doesn't really work with passwords created via diceware), but combined with the character length and possible uppercase/lowercase/number/symbol requirements, a password that generates a "red" bar or a "weak password" notification would probably not be allowed to proceed.

Support Add a password strength bar

1. Proposing this so new users could know whether their password is secure. epic genius (talk) 16:25, 5 November 2015 (UTC)
2. Many other websites already do this, and I certainly can't see the harm in doing it here. Although I personally would only want someone actually stopped from using a weak password if they were an admin, functionary, etc. Beeblebrox (talk) 18:54, 5 November 2015 (UTC)

   Maybe even then only if it is less strong than their previous password... but suppose the previous password was compromised, or part compromised? All the best: Rich Farmbrough, 19:42, 5 November 2015 (UTC).
   

   @Rich Farmbrough: The problem is that once the password has been accepted, it gets hashed down (because storing passwords in a reversable encryption is unbelievably dangerous and hashing is a one way function and difficult to computationally reverse). Your subsuggestion also runs the risk of strength creep where each time a user who is subject to the higher scrutiny will have to come up with increasingly more difficult passwords. Hasteur (talk) 19:19, 12 November 2015 (UTC)

   @Hasteur:

   1. When someone is changing a password the old password is also given. Hence there is no need for reversible encryption.
   2. My sub-suggestion was including the condition the the new password be "weak" for some definition of weak.

   All the best: Rich Farmbrough, 20:06, 12 November 2015 (UTC).
   

   @Rich Farmbough: Ok, I'll dismiss point one, however point 2 still stands unless the user is creating procedural passwords (ex: CorrectHorseBatteryStaple1, CorrectHorseBatteryStaple2, CorrectHorseBatteryStaple3, etc.) they're going to keep raising the lower limit for password complexity through the "Maybe even then only if it is less strong than their previous password the least strong password you could have would be equal to the current password strength (barring the foundation raising the strength level) as you could never enter a wearker password and users will run into a race condition of causing themselves a very strong password and then never be able to go to a relatively simpler one. Hasteur (talk) 20:50, 12 November 2015 (UTC)

3. Support. All the best: Rich Farmbrough, 19:42, 5 November 2015 (UTC).
   
4. Effective and lets the user decide the risk he or she wants to take. sst✈^discuss 04:50, 6 November 2015 (UTC)
5. Support The more incentives for having a good password, the better. --DSA510 Pls No Bully 05:52, 6 November 2015 (UTC)
6. I can't see how this could hurt, so tentatively supporting, but how much would it help? I can't imagine it would encourage people to use worse passwords. Has this been studied? — Earwig ^talk 09:03, 6 November 2015 (UTC)

   @The Earwig: You may want to see this. Generally, participants in the study tried to make a password that was not "poor." epic genius (talk) 15:31, 6 November 2015 (UTC)

7. Conditional on a competent implementation. MER-C 19:39, 6 November 2015 (UTC)
8. These are becoming standard. I would prefer the bar to be advisory on all but admin and functionary accounts. SilkTork ^{✔Tea time} 11:25, 8 November 2015 (UTC)
9. Pretty much the norm on every website these days, Would really make sense to have one here aswell. –Davey2010^Talk 04:58, 10 November 2015 (UTC)
10. Yes, per my previous comment above.- MrX 16:58, 11 November 2015 (UTC)
11. Great idea and gives users an indication of whether their password is strong or weak. Its only an indicator though.Blethering Scot 21:47, 13 November 2015 (UTC)
12. This would probably reduce the number of users with new weak passwords, even without any enforcement. עוד מישהו Od Mishehu 22:31, 15 November 2015 (UTC)
13. Per above Best proposal here. Should be simple to implement. ---- Patar knight - ^chat/_{contributions} 04:01, 20 November 2015 (UTC)
14. Not intrusive, but would hopefully remind/encourage people to create a strong password. I would support Epicgenius' suggestion of including it in the Preferences option to change your password as well. — Bilorv_(talk)^(c)(e) 17:41, 20 November 2015 (UTC)
15. Support, but the devil is in the details. The strength checker needs to say that "nine out of ten wikipedia editors love jimbo" is strong, "Wikipedia; The Free Encyclopedia That Anyone Can Edit" is weak, "btulvkzhrrmnjgcmqeae" is strong and "6Kx4#Nf!" is weak. --Guy Macon (talk) 22:11, 20 November 2015 (UTC)
16. Support but make it take into account the usual rubbish such as first letter capital, adding 1 on the end, and stuff that's hard to remember and mark these down. Stifle (talk) 10:29, 23 November 2015 (UTC)
17. Support Preferably based on listings most common passwords or proper entropy calculations and not just some silly "Ooooh, a digit, you get a point" sort of sentiment. Written well, this should actually inform people about security, rather than just following arbitrary rules. Happy Squirrel (talk) 20:53, 3 December 2015 (UTC)
18. Chris Troutman (talk) 21:21, 5 December 2015 (UTC)
19. I'm for any feedback indicator in this regard czar 04:27, 7 December 2015 (UTC)

Oppose Add a password strength bar

1. Password strength bars vary between "useless" and "worse than useless" when it comes to creating truly secure passwords. The passwordmeter.com bar, for example, considers "Password1!" to be an example of a strong password. --Carnildo (talk) 02:50, 6 November 2015 (UTC)

   The WMF would not base the password determination technology off passwordmeter.com—that would be copyrighted. The determination of a "secure password" would come about when the 10,000-common-password-list is factored in... or not. (Plus, David Stutz's password bar gives "Password1!" as a red bar, which would then not be accepted under my suggestion.) epic genius (talk) 03:07, 6 November 2015 (UTC)

   I'd recommend zxcvbn (demo), used by Dropbox, Wordpress.com, Splunk and (as I understand it) usually favourably reviewed (disclosure: the author is a coworker). LFaraone 04:24, 30 November 2015 (UTC)

Comment Add a password strength bar

• This bar should also probably be applied to "Change your password" in Special:Preferences as well. epic genius (talk) 19:53, 5 November 2015 (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.

Email editors if their email address was included in a breach

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.

---

Most breaches occur because they are registered on a website that has been breached. If an editor uses the same password for that site or that email/Wikipedia, their account can be compromised without password cracking. The breach tracking website "Have I been pwned?" has an API for mass-checking emails.

Support Email editors if their email address was included in a breach

Oppose Email editors if their email address was included in a breach

• Sadface oppose - unless a special agreement was reached with "Have I been pwned?" this would constitute a breach of privacy, by sending the email addresses to their web site. All the best: Rich Farmbrough, 14:26, 6 November 2015 (UTC).
  

Comment Email editors if their email address was included in a breach

• How would the WMF go about looking for email addresses included in breaches? That is way out of their purview. epic genius (talk) 21:47, 5 November 2015 (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.

Detect suspicious logins

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.

---

Log the geolocation of all IPs for 12-24 hours. If the great circle distance (in meters) between the geolocation of a login and the last login looks suspicious for the amount of time that has passed, email the editor to authorize the login. While this measure is less effective for inactive editors, active editors who login frequently would not have their accounts easily breached by hackers halfway across the globe.

Support Detect suspicious logins

1. Sounds useful, at least as an optional feature. An extra feature could be to offer users to disable login or disable certain user rights (such as the right to chang the password) from certain countries. --Stefan2 (talk) 16:53, 16 November 2015 (UTC)
2. Support - provided that this information isn't shared with anyone except the user in question. This can obviously be tested using special testing accounts shared by multiple people at appropriate distances. It should be noted, though, that geolocation isn't perfect, and that such logins may be perfectly legitimate. עוד מישהו Od Mishehu 21:34, 16 November 2015 (UTC)
3. Conditional support Sounds interesting, but it'd just be a nuisance to editors who need to use proxies to edit, me included. It should definitely be optional. Zhaofeng Li [talk ♦ contribs] 11:49, 22 November 2015 (UTC)
4. Support with opt-out. Also, it is important that we not prescribe the precise parameters; maybe the MediaWiki developers find certain values have too many false positives, or decide to apply another threat-scoring mechanism. LFaraone 04:26, 30 November 2015 (UTC)

Oppose Detect suspicious logins

1. Geolocation data is FAR too inaccurate to depend on for this sort of thing. HighInBC 01:44, 22 November 2015 (UTC)

   @HighInBC:We're not talking about blocking an account for being compromised just because there was a login from the wrong part of the world; we're talking about an attempted login from Australia within a few hours of the user in question logging in from Canada - and if the software does nothing but inform the user in question, what harm is done? עוד מישהו Od Mishehu 22:08, 22 November 2015 (UTC)

   A notification would be nice. However the proposal is to "email the editor to authorize the login". This means prevent the login until the user checks their e-mail. The would at the very least need to be a default off option. HighInBC 22:17, 22 November 2015 (UTC)

2. Notifications sound great, particularly when someone instantly travels thousands of miles. But Geo-location isn't reliable enough to justify requiring an email confirmation to login, unless it was an opt-in security feature. Monty₈₄₅ 04:03, 30 November 2015 (UTC)

Comment Detect suspicious logins

I'm concerned about the false-positive rate if this is implemented. I once moved 300 miles just by resetting my router -- my old IP address was correctly geolocated, while the new one geolocated to my ISP's regional headquarters. --Carnildo (talk) 02:38, 17 November 2015 (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.

User groups to apply password requirement to

Password requirements for Crats, Stewards and Founder groups

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.

---

Also request that Global functionaries including these groups have the same requirement.

The group of users with the these flags (currently 32,0 ,1 - locally) and therefore the ability to do some quite nasty stuff.

Note: Currently all local Crats, Stewards and Founders are also admins.

Support Password requirements for 'Crats, Stewards and Founder groups

1. Absolutely. These are the people who can really wreck stuff, mass de-sysop, etc. All the best: Rich Farmbrough, 21:15, 5 November 2015 (UTC).
   
2. For 'crats. — Earwig ^talk 09:03, 6 November 2015 (UTC)
3. For bureaucrats and the founder? Definitely, although this is kinda redundant, per WTT's comment below. However, it can't be placed on stewards unless this is proposed on meta. epic genius (talk) 15:29, 6 November 2015 (UTC)
4. Certainly. JohnCD (talk) 22:25, 6 November 2015 (UTC)
5. Not sure if we can do anything here but if we can then ofcourse!. –Davey2010^Talk 05:01, 10 November 2015 (UTC)
6. Support: I posted below that "A 16 byte password is not necessary for someone who'll create an account, edit a couple of times, and then forget about Wikipedia [or the editing side of it] completely." Targeting only those with the power to do a lot of damage will avoid any disadvantages from enforcing strict requirements. — Bilorv_(talk)^(c)(e) 17:41, 20 November 2015 (UTC)
7. Support: A sensible place to start, even if we later decide to make the requirements universal. --Guy Macon (talk) 22:23, 20 November 2015 (UTC)
8. Support. Yann (talk) 10:31, 30 November 2015 (UTC)
9. Chris Troutman (talk) 21:21, 5 December 2015 (UTC)

Oppose Password requirements for 'Crats, Stewards and Founder groups

Comments Password requirements for 'Crats, Stewards and Founder groups

1. Stewards are a global group, so I don't think we can decide this here, and surely we don't need to set unique password restrictions on Jimbo (given he's already a functionary)? — Earwig ^talk 09:03, 6 November 2015 (UTC)
   • You are right of course that he currently has those bits. It is not beyond the realms of possibility that he might surrender them, he has surrendered most of his super-powers over the years, at least in name. It is obscure what rights come with the Founder bit, it would seem worth including it. All the best: Rich Farmbrough, 14:30, 6 November 2015 (UTC).
     
2. There are no crats or founders that are not admins. I'd prefer we just point it at that group. Worm^TT(talk) 14:33, 6 November 2015 (UTC)

This one doesn't really make any sense as we cannot dictate global policy from here, and only global policy can dictate what stewards (and probably Jimmy as well) must do. Beeblebrox (talk) 20:01, 8 December 2015 (UTC)

Without wishing to appear rude, I'll point out that an RfC is a request for comments, not a vote to decide on implementation. It seems to me that if this needs to be raised at a more global venue - presumably meta - there would still be value in obtaining comments from the English Wikipedia as that would help inform the debate elsewhere. FWIW I think there is value in encouraging/educating most users with advanced permissions to use an unique strong password or passphrase, but I don't think that compulsion is the best means of getting volunteers to comply. --RexxS (talk) 00:16, 9 December 2015 (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.

Password requirements for Functionary group

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 group of users who have access to non-public data (less than 100) i.e. those with WP:Checkuser or WP:Oversight user-rights - Wikipedia:Functionaries

Support Password requirements for Functionary group

1. Definitely Worm^TT(talk) 10:47, 5 November 2015 (UTC)
2. Absolutely. Callanecc (talk • contribs • logs) 11:14, 5 November 2015 (UTC)
3. At a minimum, something should be applied. --kelapstick^(bainuu) 11:52, 5 November 2015 (UTC)
4. Definitely. Sam Walton (talk) 12:09, 5 November 2015 (UTC)
5. The damage that could be done is quite significant so something needs to be put in place.— Preceding unsigned comment added by Amortias (talk • contribs) 12:29, 5 November 2015
6. With access to the most sensitive data, a stronger password is required. Elockid ^{Message me} 13:12, 5 November 2015 (UTC)
7. Can't be anything wrong with letting rogue functionaries steal all these data. :p epic genius (talk) 14:22, 5 November 2015 (UTC)
8. Yes Hasteur (talk) 15:59, 5 November 2015 (UTC)
9. Certainly.--Ymblanter (talk) 17:52, 5 November 2015 (UTC)
10. Agree. BMK (talk) 18:31, 5 November 2015 (UTC)
11. After the discussion we had on the functuionaries mailing list since this incident unfolded, I think it is safe to say that this scared the crap out of us and nobody feels that it would be a burden to comply with any reasonable new requirements. Beeblebrox (talk) 18:56, 5 November 2015 (UTC)
12. This is essential. BethNaught (talk) 19:24, 5 November 2015 (UTC)
13. Absolutely. Anyone who fails should be de-functionaried today and for ever as having total lack of clue. All the best: Rich Farmbrough, 20:28, 5 November 2015 (UTC).
    
14. Support The stronger the better, especially considering that these accounts have access to such sensitive data. --DSA510 Pls No Bully 05:55, 6 November 2015 (UTC)
15. Of course. — Earwig ^talk 09:03, 6 November 2015 (UTC)
16. Obviously. MER-C 17:50, 6 November 2015 (UTC)
17. Absolutely. JohnCD (talk) 22:25, 6 November 2015 (UTC)
18. Mkdw^talk 22:22, 7 November 2015 (UTC)
19. Support, certainly. — xaosflux ^Talk 15:48, 8 November 2015 (UTC)
20. As these accounts work with sensitive stuff & whatnot it only makes sense to have a much better password. –Davey2010^Talk 05:03, 10 November 2015 (UTC)
21. Yes, this would seem to be an obvious necessity. ​—DoRD (talk)​ 01:13, 11 November 2015 (UTC)
22. Yes. Ideally this group would be required to use two factor authentication, but the proposal is better that the current scheme. - MrX 17:21, 11 November 2015 (UTC)
23. No-brainer. —zziccardi (talk) 02:37, 16 November 2015 (UTC)
24. Per above Obvious first step. ---- Patar knight - ^chat/_{contributions} 04:01, 20 November 2015 (UTC)
25. Support: I posted below that "A 16 byte password is not necessary for someone who'll create an account, edit a couple of times, and then forget about Wikipedia [or the editing side of it] completely." Targeting only those with the power to do a lot of damage will avoid any disadvantages from enforcing strict requirements. — Bilorv_(talk)^(c)(e) 17:41, 20 November 2015 (UTC)
26. Support: A sensible place to start, even if we later decide to make the requirements universal. --Guy Macon (talk) 22:23, 20 November 2015 (UTC)
27. Support: As a functionary, I totally agree that those accounts security should be held to a high standard. LFaraone 04:27, 30 November 2015 (UTC)
28. Support Yann (talk) 10:32, 30 November 2015 (UTC)
29. Support These people are trusted with access to data that could expose people to harm. Outing is a big concern. Happy Squirrel (talk) 20:59, 3 December 2015 (UTC)
30. Chris Troutman (talk) 21:21, 5 December 2015 (UTC)

Oppose Password requirements for Functionary group

---

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.

Password requirements for Administrator group

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 group of users with the sysop flag (currently 848) and therefore the ability to see deleted data - Wikipedia:Administrators

Support Password requirements for Administrator group

1. Definitely Worm^TT(talk) 10:47, 5 November 2015 (UTC)
2. kelapstick^(bainuu) 11:55, 5 November 2015 (UTC)
3. Not as vitally important as functionaries, but still worth higher security. Sam Walton (talk) 12:09, 5 November 2015 (UTC)
4. Per Samwalton9. Amortias (T)(C) 12:30, 5 November 2015 (UTC)
5. Admins have the ability to cause site wide damage. Also, there is likely still deleted data that can be sensitive of nature, some of which could have been qualified to be suppressed but have not yet been reported. A strong password is needed. Elockid ^{Message me} 13:15, 5 November 2015 (UTC)
6. The accounts breached are admins, it makes sense to require strong passwords for all admins. sst✈^discuss 13:45, 5 November 2015 (UTC)
7. There is the same vulnerability with rogue admins as with functionaries. epic genius (talk) 14:23, 5 November 2015 (UTC)
8. I would say so, the risk is too high--Ymblanter (talk) 17:52, 5 November 2015 (UTC)
9. Agree. BMK (talk) 18:32, 5 November 2015 (UTC)
10. It is a shame that some folks who are apparently ok as admins were pretty foolish about their passwords. One of them apparently used their date of birth. At the very least there should be some firm advice ont his, but an actual rule would be more effective. Beeblebrox (talk) 18:58, 5 November 2015 (UTC)
11. Since not all admins can apparently be trusted to maintain adequate security practices. BethNaught (talk) 19:24, 5 November 2015 (UTC)

    This only covers one aspect of good security practices. All the best: Rich Farmbrough, 20:29, 5 November 2015 (UTC).
    

12. Despite my caveats above on some of the proposed requirements, I support this. Any admin who does not understand the need for a good password will benefit from the education. All the best: Rich Farmbrough, 20:31, 5 November 2015 (UTC).
    
13. Of course. — Earwig ^talk 09:03, 6 November 2015 (UTC)
14. Given that you can spread malware with administrator access, this is a necessity (it will be reverted quickly but the reputation damage will be immense). MER-C 17:52, 6 November 2015 (UTC)
15. Certainly. JohnCD (talk) 22:26, 6 November 2015 (UTC)
16. Mkdw^talk 22:22, 7 November 2015 (UTC)
17. Support. — xaosflux ^Talk 15:46, 8 November 2015 (UTC)
18. Ofcourse!. –Davey2010^Talk 05:04, 10 November 2015 (UTC)
19. This also seems to be a necessary step to take. ​—DoRD (talk)​ 01:14, 11 November 2015 (UTC)
20. Yes. - MrX 17:22, 11 November 2015 (UTC)
21. Absolutely. —zziccardi (talk) 02:39, 16 November 2015 (UTC)
22. Per above Obvious second step. ---- Patar knight - ^chat/_{contributions} 04:01, 20 November 2015 (UTC)
23. Support: I posted below that "A 16 byte password is not necessary for someone who'll create an account, edit a couple of times, and then forget about Wikipedia [or the editing side of it] completely." Targeting only those with the power to do a lot of damage will avoid any disadvantages from enforcing strict requirements. — Bilorv_(talk)^(c)(e) 17:41, 20 November 2015 (UTC)
24. Support: A sensible place to start, even if we later decide to make the requirements universal. --Guy Macon (talk) 22:23, 20 November 2015 (UTC)
25. Support Yann (talk) 10:32, 30 November 2015 (UTC)
26. Chris Troutman (talk) 21:21, 5 December 2015 (UTC)

Oppose Password requirements for Administrator group

1. admins have no rights that can compromise anything in the function of WP. So raised limits for their (our) passwords are irrelevant. --h-stt !? 14:23, 24 November 2015 (UTC)

This is incorrect - Admins have the ability to edit site javascript (As well as personal javascript of any individual user). Someone who knows what they are doing could use this to take over any arbitrary account or extract potentially personally identifying information from any user, or just break the site totally. Bawolff (talk) 00:22, 1 December 2015 (UTC)

Comments Password requirements for Administrator group

• What about for admins who have been inactive but don't have email? How should we reset their passwords, let alone notify them about it? epic genius (talk) 20:35, 5 November 2015 (UTC)

  How many of them are there? (There might be none.) And I think the process is that the system insists you change your password as part of the log-in procedure, so there is still a window of opportunity to compromise those accounts, however reducing the number of (potential) admin accounts with weak(ish) passwords is good work. It reduces the cross-section of the attack. All the best: Rich Farmbrough, 21:11, 5 November 2015 (UTC).
  

  I expect their passwords would become invalid when they next try to log in with them. If they're inactive, then it doesn't get reset. Worm^TT(talk) 08:36, 6 November 2015 (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.

Password requirements for Edit Filter Manager group

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 group of users with the EFM flag (currently 170) and therefore the ability to break the wiki.

Support Password requirements for Edit Filter Manager group

1. It's no more dangerous than an admin account - since they have access to the functionality by granting it to themselves. But aside from the privacy issues of seeing deleted stuffs, this is one of the operationally most potent bits there is. All the best: Rich Farmbrough, 21:06, 5 November 2015 (UTC).
   
2. Edit filter managers could create malicious edit filters if the accounts are hijacked; some of these edit filters could potentially automatically prevent users from editing articles, just as admins could. epic genius (talk) 21:18, 5 November 2015 (UTC)
3. This is another group I'd support any requirements being applied to. Worm^TT(talk) 08:32, 6 November 2015 (UTC)
4. EFMs are effectively mini-admins. Given that it involves a certain amount of private data (not a whole lot, but private filters can be exploited), I tentatively agree. — Earwig ^talk 09:03, 6 November 2015 (UTC)
5. Support, as this group can be granted ad-hoc, and can be disruptive to large number of editors. — xaosflux ^Talk 15:47, 8 November 2015 (UTC)
6. Per above Obvious third step. ---- Patar knight - ^chat/_{contributions} 04:01, 20 November 2015 (UTC)
7. Support: I posted below that "A 16 byte password is not necessary for someone who'll create an account, edit a couple of times, and then forget about Wikipedia [or the editing side of it] completely." Targeting only those with the power to do a lot of damage will avoid any disadvantages from enforcing strict requirements. — Bilorv_(talk)^(c)(e) 17:41, 20 November 2015 (UTC)
8. Support: A sensible place to start, even if we later decide to make the requirements universal. --Guy Macon (talk) 22:23, 20 November 2015 (UTC)
9. Support Yann (talk) 10:33, 30 November 2015 (UTC)
10. Chris Troutman (talk) 21:21, 5 December 2015 (UTC)

Oppose Password requirements for Edit Filter Manager group

Comments Password requirements for Edit Filter Manager group

1. The argument I post above does not fully convince me. (Even really bad actions can be undone quickly, and EFMs are as blockable as anyone.) But the burden is pretty light, and the number of EFMs that are not Admins is very small. All the best: Rich Farmbrough, 21:06, 5 November 2015 (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.

Password requirements for Template Editor group

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 group of users with the Template Editor flag (currently 118) and therefore the ability to do some quite nasty stuff.

Support Password requirements for Template Editor group

Oppose Password requirements for Template Editor group

1. Yes, there is vandalism leverage, but it is subject to reverts, and blocks. All the best: Rich Farmbrough, 21:01, 5 November 2015 (UTC).
   
2. Can they vandalize? Yes. Can it cause people to be prevented from editing a page, like a rogue admin or edit filter manager could? No. epic genius (talk) 21:19, 5 November 2015 (UTC)
3. No private data involved; I don't see a strong reason. — Earwig ^talk 09:03, 6 November 2015 (UTC)
4. No point as any template edits can be reverted and the compromised account blocked. –Davey2010^Talk 05:06, 10 November 2015 (UTC)
5. Per above Easily fixed if compromised and without much ramifications. ---- Patar knight - ^chat/_{contributions} 04:01, 20 November 2015 (UTC)
6. Chris Troutman (talk) 21:21, 5 December 2015 (UTC)

Comments Password requirements for Template Editor group

---

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.

Password requirements for users with AutoWikiBrowser access

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 group of users with access to AWB and therefore the ability to quickly make large numbers of repetitive edits - Wikipedia:AutoWikiBrowser

Support Password requirements for users with AutoWikiBrowser access

1. An account with AWB access can, for example, redirect articles to pages like Fellatio or Gay Nigger Association of America, at a rate of over 50 edits a minute. This can cause quite a bit of disruption. sst✈^discuss 14:06, 5 November 2015 (UTC)
2. Chris Troutman (talk) 21:21, 5 December 2015 (UTC)

Oppose Password requirements for users with AutoWikiBrowser access

1. Difficult as AWB access is not a user-right, but a tool with a list of users who can use the tool. If that sort of disruption was intended there are other ways to do it. Worm^TT(talk) 14:09, 5 November 2015 (UTC)
2. Not only is this not a user right (so the WMF cannot enforce this), but AWB access isn't as disruptive as admin access. A quick quick quick quick block of errant AWB users, and an instant rollback, should do the trick. Generally, though, I would support minimum password requirements for people with advanced user rights, like rollback, template editor, abuse filter manager, or account creator (and maybe even mass message sender). epic genius (talk) 14:28, 5 November 2015 (UTC)
3. AWB is a tool, not a user group. They have already managed to shoehorn WP:PERM admins into being part of their screening process by requiring rollback first. I don't think this is appropriate. Beeblebrox (talk) 19:00, 5 November 2015 (UTC)
4. Per others. BethNaught (talk) 19:24, 5 November 2015 (UTC)
5. Oppose Because <pre-redacted per WP:BEANS> this does nothing special for security. All the best: Rich Farmbrough, 19:44, 5 November 2015 (UTC).
   
6. No reason why AWB should be special. Plus, this makes what is currently a fairly simple approvals process a lot more complicated, and if someone cared enough to try to compromise an AWB account, it'd be much simpler to just run a bot with the API. — Earwig ^talk 09:03, 6 November 2015 (UTC)
7. Oppose, this should be the same as any other user account requirements. — xaosflux ^Talk 15:48, 8 November 2015 (UTC)
8. No point as any AWB edits can be reverted and the account can be blocked. –Davey2010^Talk 05:08, 10 November 2015 (UTC)
9. Per above Easily fixed if compromised and without much ramifications. ---- Patar knight - ^chat/_{contributions} 04:01, 20 November 2015 (UTC)
10. No. I am perfectly capable of writing a program that does what AWB does. Automated edits may be a problem, but this is the wrong solution. --Guy Macon (talk) 22:23, 20 November 2015 (UTC)

Comments Password requirements for users with AutoWikiBrowser access

• I think we should treat the assortment of non-functionary non-admin user rights or accesses under the umbrella of 'all users'. There are simply too many of these (ACC,Template Editor, AfC reviewer, etc.) for it to be feasible for us to discuss each one in a different way. Sam Walton (talk) 14:13, 5 November 2015 (UTC)
• This seems out of scope for this RFC since AWB is not MediaWiki. That said, a separate discussion in the context of AWB's pages could plausibly come up with consensus for something similar to this. --Izno (talk) 15:18, 5 November 2015 (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.

Password requirements for All users

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.

---

All users (currently 48,459,957) should follow these password requirements.

Support Password requirements for All users

1. Wikimedia passwords never have to be changed, so there's no harm in forcing a complex password. If the password has a 90 day expiry (for example) that's a different matter as people will start writing them down. QuiteUnusual (talk) 11:04, 5 November 2015 (UTC)

   My understanding from the WMF Security team member is that if you try to log in with a password which does not meet the requirement, you will be forced to change it. Worm^TT(talk) 11:12, 5 November 2015 (UTC)

   The password still has to be remembered (or recorded some other way). All the best: Rich Farmbrough, 20:36, 5 November 2015 (UTC).
   

Oppose Password requirements for All users

1. I think that forcing all users to conform to these new requirement is probably overkill. Worm^TT(talk) 10:47, 5 November 2015 (UTC)
2. At this stage I'm sitting here, although there may be other usergroups which should have these password requested implemented (template editor and edit filter managers are the big one I can think of). Callanecc (talk • contribs • logs) 11:11, 5 November 2015 (UTC)
3. I don't think this is necessary. --kelapstick^(bainuu) 11:54, 5 November 2015 (UTC)
4. Would hurt editor retention. sst✈^discuss 13:44, 5 November 2015 (UTC)
5. Given that it's easier to create an account than to crack a password, this would do virtually nothing to promote site security, but will annoy/inconvenience thousands upon thousands of editors. The Big Bad Wolfowitz (aka Hullaballoo) (talk) 13:52, 5 November 2015 (UTC)
6. The vast majority of registered users don't make more than a couple edits with an account. Why affect them if they are not going to log into their accounts anyway? Also, this is not an incentive for editors. epic genius (talk) 15:36, 5 November 2015 (UTC)
7. Strongly – a number of us aren't interest in Admin'ing precisely because we don't want to have deal with stuff like this. Also, if a "regular" account gets compromised, it shouldn't be too big an issue for Admins to shut down any resulting malarkey quickly. --IJBall (contribs • talk) 17:18, 5 November 2015 (UTC)
8. Users who do not have access to sensitive data should decide themselves whether risk to have their account broken is sufficient.--Ymblanter (talk) 17:54, 5 November 2015 (UTC)
9. There's no increased security for Wikipedia in this. BMK (talk) 18:29, 5 November 2015 (UTC)
10. We don't want to make it harder to get started. Increased standards for users with advanced perissions is one thing, forcing it on every single account is a bit much. Beeblebrox (talk) 19:02, 5 November 2015 (UTC)
11. Not necessary for Wikipedia's security. Will deter sign-ups. BethNaught (talk) 19:24, 5 November 2015 (UTC)
12. Users are responsible for their own security. We want them to remember their password when they make a second edit 6 months later. Let them make the judgement call. All the best: Rich Farmbrough, 20:36, 5 November 2015 (UTC).
    
13. No strong reason for this in general. — Earwig ^talk 09:03, 6 November 2015 (UTC)
14. Not necessary. JohnCD (talk) 22:26, 6 November 2015 (UTC)
15. Considering that "anyone can edit" without even needing an account, and that there's very little an established account can do that a new 10-edit 4-day account can't, there doesn't really seem to be any security to protect. 823510731 (talk) 17:43, 7 November 2015 (UTC)
16. This would discourage registration and possibly editing altogether. Reach Out to the Truth 18:14, 7 November 2015 (UTC)
17. I worry this would complicate the process of editing and steer writers away from the project, especially those without strong computer skills. Mkdw^talk 22:25, 7 November 2015 (UTC)
18. To be honest I'm on the fence with this but all in all I guess again Commonsense should prevail - You should pick a good password & all that, If an account does get hacked the worst they can do is vandalize an article for about 10 minutes before getting blocked and as noted above some editors only sign up and don't edit once so again I guess kinda pointless & unnecessary. –Davey2010^Talk 05:14, 10 November 2015 (UTC)
19. I would only consider this if IP editors were required to register for an account.- MrX 17:24, 11 November 2015 (UTC)
20. Per above Overkill. ---- Patar knight - ^chat/_{contributions} 04:01, 20 November 2015 (UTC)
21. A 16 byte password is not necessary for someone who'll create an account, edit a couple of times, and then forget about Wikipedia [or the editing side of it] completely. When we have the amazing technical ability to restrict password checks to those with enough rights to do any widespread damage, I don't understand why we would choose instead to make everybody follow strict rules. Most accounts have nothing worth hacking into for. — Bilorv_(talk)^(c)(e) 17:41, 20 November 2015 (UTC)
22. I think we need some lightweight requirements for ordinary editors and heavyweight requirement for anyone with the power to do hard-to-undo harm. --Guy Macon (talk) 22:23, 20 November 2015 (UTC)
23. Overkill. Regular accounts without teh bits don't threaten the wiki quite to the degree as other user groups. Chris Troutman (talk) 21:21, 5 December 2015 (UTC)

Comment Password requirements for All users

• Not sure on this one yet, waiting to hear what other users have to say. Sam Walton (talk) 12:10, 5 November 2015 (UTC)
• The damage that can be caused is minimal and only slightly more than what could be caused by an IP. Some users with additional rights might need this template editors ACC accounts as the damage that could be done by screwing with a protected template may be significant. Amortias (T)(C) 12:32, 5 November 2015 (UTC)

  Yes I'd add EFM and maybe TE. All the best: Rich Farmbrough, 20:36, 5 November 2015 (UTC).
  

1. Requiring long, hard to remember passwords would do more harm than good. A lot of strong contributors start out by making a marginal number of edits from time to time before becoming more engaged, and I'm worried that many such editors may be turned off entirely if they can never remember their password. Also, only a few thousand accounts have any permission beyond autoconfirmed (which is easily obtained), so a person who compromises a run-of-the-mill account is not going to be able to do much more damage to Wikipedia beyond what they could do if they directly created a vandal account. Spirit of Eagle (talk) 02:38, 7 November 2015 (UTC)

• In an office I once worked at, the IT department decided to enforce strong password requirements with 90-day expiry periods. During an audit approximately six months later, they were aghast to discover that about 20% of the office staff had written down their passwords and put them in not-very-safe locations (like on post-it notes on their monitors, or in unlocked desk drawers). External software (like password keepers) was not permitted unless approved by the IT department (and they never approved anything that wasn't mandated by corporate management). Prior to the change, nobody had been known to keep their passwords in unsafe locations like this, so the change actually reduced the overall security of the system, although I don't believe there was a breech because of it. FYI this was a minor office of a major company that is known worldwide.Etamni | ✉ | ✓  13:49, 6 December 2015 (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.

Regular auditing

For those users with emails set, a simple audit can check against passwords from publicly published email breaches. If identified, the user can be contacted to change their password. This is apparently what happened in the recent situation.

Regular audits for Functionary group

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.

---

Regular audits for the group of users who have access to non-public data (less than 100) i.e. those with WP:Checkuser or WP:Oversight user-rights - Wikipedia:Functionaries

Support Regular audits for Functionary group

1. Definitely. Worm^TT(talk) 10:47, 5 November 2015 (UTC)
2. Support. QuiteUnusual (talk) 11:04, 5 November 2015 (UTC)
3. Absolutely. Elockid ^{Message me} 13:08, 5 November 2015 (UTC)
4. Support this idea. In addition, force a password reset every once in a while. epic genius (talk) 15:39, 5 November 2015 (UTC)
5. With details to be figured out.--Ymblanter (talk) 17:55, 5 November 2015 (UTC)
6. Agree. BMK (talk) 18:33, 5 November 2015 (UTC)
7. Essential. BethNaught (talk) 19:24, 5 November 2015 (UTC)
8. Obviously yes. --DSA510 Pls No Bully 05:58, 6 November 2015 (UTC)
9. In some form, yes. — Earwig ^talk 09:03, 6 November 2015 (UTC)
10. Buy a bunch of GPUs, install Hashcat and set it loose. MER-C 17:53, 6 November 2015 (UTC)
11. Absolutely!. –Davey2010^Talk 05:15, 10 November 2015 (UTC)
12. I support the idea behind this, as long as it doesn't create additional potential data breaches. ​—DoRD (talk)​ 01:18, 11 November 2015 (UTC)
13. I support completely. Stuartyeates (talk) 21:36, 15 November 2015 (UTC)
14. Yep! —zziccardi (talk) 02:54, 16 November 2015 (UTC)
15. Per above As long as it's in line with our privacy policies and applicable laws ---- Patar knight - ^chat/_{contributions} 04:01, 20 November 2015 (UTC)
16. Support as long as the audit is done by trusted WMF employees without exposing sensitive data. Zhaofeng Li [talk ♦ contribs] 11:39, 22 November 2015 (UTC)
17. Support Yann (talk) 10:34, 30 November 2015 (UTC)
18. Chris Troutman (talk) 21:21, 5 December 2015 (UTC)

Oppose Regular audits for Functionary group

1. This is not actually an oppose. It's request to think this through, and maybe re-word it. What is to be audited? (Ideally it would be the use of the tools but I doubt that would gain traction!) I suspect the proposer means the nominal password strength. (Nominal because, for example, I happen to know Dave's password is "WTTDoomBar4%" which counts as "secure" but isn't.) The passwords are not available until an attempted login in made. At that point any action taken with the password risks leaving a footprint. SOP is to encrypt it and overwrite the memory space that contained the unencrypted variable. All the best: Rich Farmbrough, 19:53, 5 November 2015 (UTC).
   

   I was presuming that it meant a request for the WMF to compare its list of password hashes against hashes of publicly known passwords. It is not necessary to attempt to brute-force entry; that could be done but would be less efficient than a server-side cracking attempt. BethNaught (talk) 19:55, 5 November 2015 (UTC)

   Beth this is a species of brute-forcing known as a dictionary attack. Depending on the number of bits of salt (again nominally the obvious meaning of bits) one requires a proportionally larger or smaller dictionary. The standard used to be, I think 4096 possible salts, which is 12 bits. (It is trivial to modify the crypt to use many more bits - and something many unix sites used to do - or indeed to add a few extra rounds of the encryption function.)

   The way to do this, if it is decided to do it, is with a clean machine, loaded with the necessary tools and the password/shadow files, in a clean room, off any network. The results are printed and scanned (or typed - hopefully there won't be many accounts) and the machine wiped completely (and recycled as fire-lighters).

   All the best: Rich Farmbrough, 20:46, 5 November 2015 (UTC).
   

   @Rich Farmbrough: The audits would be of the form of regularly checking if email address were included in a breach, and possibly against lists of common passwords. Checking for nominal password strength hasn't been mentioned. Worm^TT(talk) 08:30, 6 November 2015 (UTC)

   Thanks for the clarification. You say "hasn't been mentioned" - as if there was a discussion elsewhere? All the best: Rich Farmbrough, 14:33, 6 November 2015 (UTC).
   

   If I wasn't clear, I went searching for someone in the WMF who might help with these issues in light of compromised admin accounts. When I found someone, I had a quick discussion and then brought some suggestions here for the "quick wins". So, when I say "hasn't been mentioned" I meant in the conversations with the Security Team staff member. I fully intend to carry on pushing for better security after this RfC Worm^TT(talk) 14:40, 6 November 2015 (UTC)

   BethNaugh: I don't think comparing hashes is particularly useful. I don't know what wikimedia uses, but many of the public hashes would be some other hash. You need to generate your own hashes from a list of passwords as Rich Farmbrough mentioned. Nil Einne (talk) 23:19, 12 November 2015 (UTC)

• I do not see how this can be reliably done without breaching the privacy policy. Might be justifiable for checkuser/oversighter (these groups do have access to information that is covered under the privacy policies), but I can't see it for admin accounts. Believe it or not, Wikipedia administrator accounts aren't all that valuable. Risker (talk) 06:00, 7 November 2015 (UTC)

1. I don't think it's a good idea to regularly expose the encrypted hash/password file. Once the encrypted table is leaked, it can be cracked. the best method is to leave it alone and track access. "ypcat passwd" should return "*" in the password field and that was done for that very reason. In addition, having strict policy on access reduces the "I thought running crack on the password file was part of my job for security." Too many chefs means that he password file will get out even if encrypted. --DHeyward (talk) 23:38, 10 November 2015 (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.

Regular audits for Administrator group

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.

---

Regular audits for the group of users with the sysop flag (currently 848) and therefore the ability to see deleted data - Wikipedia:Administrators

Support Regular audits for Administrator group

1. Definitely. Worm^TT(talk) 10:47, 5 November 2015 (UTC)
2. Support. QuiteUnusual (talk) 11:04, 5 November 2015 (UTC)
3. Strong support. But this should be expanded to require ALL admins to have an email address set. Elockid ^{Message me} 13:10, 5 November 2015 (UTC)

   Inclined to support the "email" part. It seems a minor requirement. Note that having an email set does not mean that "email this user" is necessarily enabled.

   However remember that the email account is a second point of attack. If this is compromised the Wikipedia account is wide open.

   All the best: Rich Farmbrough, 20:52, 5 November 2015 (UTC).
   

4. Support this idea. In addition, force a password reset every once in a while. epic genius (talk) 15:39, 5 November 2015 (UTC)
5. With details to be figured out.--Ymblanter (talk) 17:55, 5 November 2015 (UTC)
6. Agree. BMK (talk) 18:33, 5 November 2015 (UTC)
7. Would be good practice. Password resets should not be mandated though, in all likelihood a similar password to before would be chosen. BethNaught (talk) 19:24, 5 November 2015 (UTC)
8. As above. — Earwig ^talk 09:03, 6 November 2015 (UTC)
9. As above. MER-C 17:54, 6 November 2015 (UTC)
10. Anyone unwilling to associate their account with an email address should not be given any form of elevated privileges. Period.  — Scott • talk 15:57, 8 November 2015 (UTC)
11. Absolutely!. –Davey2010^Talk 05:16, 10 November 2015 (UTC)
12. As above. ​—DoRD (talk)​ 01:19, 11 November 2015 (UTC)
13. I support completely. Stuartyeates (talk) 21:36, 15 November 2015 (UTC)
14. Absolutely, and I agree with Elockid and Scott. —zziccardi (talk) 02:58, 16 November 2015 (UTC)
15. Per above As long as it complies with our policies and any applicable laws. ---- Patar knight - ^chat/_{contributions} 04:01, 20 November 2015 (UTC)
16. Of course audit at my old work you could get fired if the audit team could guess your password. HighInBC 01:48, 22 November 2015 (UTC)
17. Support as long as the audit is done by trusted WMF employees without exposing sensitive data. Zhaofeng Li [talk ♦ contribs] 11:39, 22 November 2015 (UTC)
18. Support Yann (talk) 10:34, 30 November 2015 (UTC)
19. Chris Troutman (talk) 21:21, 5 December 2015 (UTC)

Oppose Regular audits for Administrator group

1. See above. All the best: Rich Farmbrough, 19:53, 5 November 2015 (UTC).
   
2. Not if it gives someone access to the encrypted password file. No one should be running crack on it. No one should be able to access it without a log and no one should be able to download it to any media. Should be fireable offense. --DHeyward (talk) 23:29, 10 November 2015 (UTC)

   No, we should make the encrypted password file publicly available and invite any and all comers to try to crack it, with a nice page where they can report which ones they cracked and a list showing who cracked and reported the most. In short order, we will have 100% uncrackable passwords. (We might want to try some common cracking dictionaries ourselves first to weed out some of the really easy ones, and not give points for brand new passwords so nobody starts "cracking" passwords they themselves entered). If someone is really good at this, the WMF might want to hire them. See Kerckhoffs's principle and Security through obscurity. --Guy Macon (talk) 00:41, 22 November 2015 (UTC)

   This is simply asking for trouble. I don't mind if WMF staffers run the audit regularly under a NDA, but disclosing it publicly is certainly going to do more harm than good. Zhaofeng Li [talk ♦ contribs] 11:37, 22 November 2015 (UTC)

   Standards bodies such as the National Institute of Standards and Technology (NIST) strongly disagree with you and specifically recommend against the practice you are advocating: "System security should not depend on the secrecy of the implementation or its components."[3] --Guy Macon (talk) 19:18, 22 November 2015 (UTC)

   I've never heard Kerckhoffs's principle be construed to mean that you should publicize password hashes. It means we should be public about the algorithm used to hash passwords, and how we're protecting them (Which we are). Bawolff (talk) 20:02, 22 November 2015 (UTC)

   It is a basic principle that applies to everything security related. "Do not rely upon anything other than your passphrases staying secret". Right now, nobody working for the WMF has any way of knowing what passwords Bawolff or Guy Macon use to log on to Wikipedia. Even an attacker who can read any file can not find out that information. Getting the hashed password file, on the other hand, can be done. Offer a bribe or make a credible threat to the right person. Exploit a zero-day bug somewhere in the millions of lines of operating system code and obtain root access, even if you are discovered and locked out after a few minutes. You cannot stop a determined attacker from obtaining the hashed password file, so don't even try. Design a system that is secure even if an attacker knows every detail about your system (which he will if he cares enough to bribe or threaten the right person) it is still secure, and verify your security be letting all potential attackers -- and your friends who may very well catch any vulnerabilities first and alert you -- know everything about your system. This is the same principle behind open-source software being more secure than proprietary software, and the counterarguments against it are the same. Shannon's Maxim: "The enemy knows the system". --Guy Macon (talk) 23:32, 22 November 2015 (UTC)

   "Even an attacker who can read any file can not find out that information" <-- What about the file /dev/mem ;). There's several reasons we want to keep hashes secret. Keeping them secret allows us to detect when someone is trying to bruteforce someone's passwords (via server logs), it allows us to change the hashing algorithm as advances are made in terms of speeds of computers (Sure, it may be infeasible now to brute force someone's password hash, but what about 10 years from now?). Additionally, in the face of users choosing stupid passwords (Which at the end of the day, is pretty hard to stop), having proper hashing/salting more slows down an attacker, rather then stops them. Bawolff (talk) 22:30, 23 November 2015 (UTC)

   There are always multiple "good reasons" for using Security through obscurity techniques such as you describe, and there are many different security through obscurity techniques, leaving the critic of such techniques in the position of playing Whac-A-Mole. There is only one "good reason" not to use security through obscurity techniques, but it is a big one: using security through obscurity techniques reduces security. --Guy Macon (talk) 09:21, 7 December 2015 (UTC)

   Naturally we want to keep the hashes secret, but security in depth requires preparation for the time when they are inadvertently revealed. I don't know the current status but how the password hashes should be secured has been investigated. See 2010-08-23 and the proposal that it points to. Ooops, I didn't read all the comments above. Some of us want the hashes to be secret! While publishing all the hashes would be courageous, the catastrophic harm that could result means it won't be tried. Johnuniq (talk) 10:00, 7 December 2015 (UTC)

   Agree that it won't be tried (and I would not waste anyone's time proposing something that I know will not pass) but I would like to emphasize that the exact same same argument is used to support all of the other security through obscurity techniques used on other sites/systems. Revealing the algorithm used to hash passwords could result in catastrophic harm. Publishing our source code could result in catastrophic harm. Allowing us to talk about security flaws on this very page could result in catastrophic harm. These are all simply variation of the basic security through obscurity technique, and they all reduce security. The reason that they all reduce security is because of basic human nature. If we attempt to keep our hashes secret (which only works if the underlying operating system has no flaws that would allow an attacker root access and every WMF employee who has root access is immune to bribes and threats), it is basic human nature that less effort will go into making our system secure even against an attacker who has access to the hashes. It also means that the only people who will be able to test our hashes for subtle or obvious flaws are WMF employees who have access to he hashes. If, on the other hand, we publish the hashes, then many people will test them for exploitable flaws, and a lot of those testers will report any flaws to WMF or at the very least publish them on the internet. I realize that some here really believe that some or all security through obscurity techniques increase security, but it is the considered opinion of the top experts in the field that all security through obscurity techniques decrease security. As I have pointed out before, an RfC is the wrong answer here. Complex technical problems with counter-intuitive technical solutions should not be voted on by a collection of a few experts and a large number of non-experts. --Guy Macon (talk) 17:07, 7 December 2015 (UTC)

   To answer Johnuniq's question: The current state is: Most passwords are hashed using the PBKDF2-sha256 algorithm with a cost of 64000, and a 128-bit salt (Basically, that's hashing using sha256 hmac 64,000 times). Some users who haven't logged in in a long time don't have their password converted to the new format. This is on the to-do list to fix. We currently do not pepper our passwords. This is also something that we will probably fix in the future. To respond to Guy - I doubt we're going to agree on this, but the reason I believe password hashes should be secret, is that they are essentially "keys". Traditionally any keys in a crypto system are kept secret. Bawolff (talk) 22:40, 7 December 2015 (UTC)

   @Bawolff: Thanks for info. That strategy, combined with the fact that inactive admins are desysopped after 12 months, should mean that everyone with advanced permissions has a well-secured hash, I suppose (I think MediaWiki 1.24 with the feature has been at enwiki for just over a year). Johnuniq (talk) 23:07, 7 December 2015 (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.

General discussion

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section.

• Worm, firstly thank you for setting all of this up!! I have a (hopefully) quick question for you: why did you include functionaries who previously had access to non-public data? Callanecc (talk • contribs • logs) 11:06, 5 November 2015 (UTC)

  I was trying to describe the functionary group to be honest, there are some users in there who are ex-arbs, without CU or OS. That said, if they don't have CU/OS, they probably needn't be included. Worm^TT(talk) 11:09, 5 November 2015 (UTC) - I've updated to focus on CUOS [4] Worm^TT(talk) 11:11, 5 November 2015 (UTC)

Great job Worm - I'd take it a bit further and have a set of trusted users run a password cracker on wikipedia passwords (especially those of the trusted users ) to check for passwords that are way to simple (like birthdates, one bit passwords, repeating passwords), per that last two compromised accounts. Both of them were very lucky a white hat revealed the passwords as insecure! KoshVorlon 11:51, 5 November 2015 (UTC)

Kosh, this was done, and the list posted on the Main Page (or somewhere similar) much to the amusement of all. I have run password crackers in the past (pre-Rainbow tables but including some nifty algorithmic, data and machine-code optimisation of my own), and you always get a load of memorable hits.

I'm not wholly opposed to this, but I think that the risk of making copies of the shadow password file is quite large.

All the best: Rich Farmbrough, 19:59, 5 November 2015 (UTC).

The way this is structured, I'm not sure it'd be easy for a consensus to form of the need for some types of changes for some users and others for others. For example, I think I'd probably support some change for all, and more stringent for functionaries. --Dweller (talk) 12:26, 5 November 2015 (UTC)

I know nothing about the law in the US, but in the UK you are almost certainly committing an offence under Section 1 of the Computer Misuse Act if you run a password cracking attempt unless you have explicit authorisation from the WMF to do it (as they own the servers). I would prefer the WMF took ownership for any security checking rather than having users, no matter how trusted, do it. QuiteUnusual (talk) 13:26, 5 November 2015 (UTC)

QuiteUnusual I think IAR would be good to apply in this situation (trusted users only, however ), for the good of Wiki security, we just had two admins have their account compromised, the white hat that did it was good enough not to take advantage of it, but rather, alert us to it, hence this entire RFC. KoshVorlon 13:45, 5 November 2015 (UTC)

That's okay, but don't do it if you are in the UK. Wikipedia may have a policy of IAR, but the UK justice system doesn't! QuiteUnusual (talk) 13:49, 5 November 2015 (UTC)

Every justice system that relies on human enforcement has IAR practices. They just have different criteria as to which rules to ignore. The Big Bad Wolfowitz (aka Hullaballoo) (talk) 13:56, 5 November 2015 (UTC)

It was pointed out on the BN that the easiest way in the future to compromise an account would be to take over a former administrator account who didn't leave under a cloud and make a request to regain the tools. Would it be feasible to run a password cracking attempt for former admins as well? Or have any former admins who request the tools returned to undergo more scrutiny than they currently receive? Liz ^{Read! Talk!} 15:04, 5 November 2015 (UTC)

First, I'd like to thank Worm That Turned for creating this RFC. Second, in reply to QuiteUnusual's concern, if the WMF does the password audits, password strength checkers, etc., there's nothing to worry about. epic genius (talk) 15:45, 5 November 2015 (UTC)

I also have another question. Will this apply globally (to MetaWiki, Commons, Wikidata, all that stuff) or just to English Wikipedia? Because if someone could still create an account with a weak password on Commons or another project, then the SUL will automatically create the weak account here, where the password could be easily cracked. epic genius (talk) 15:47, 5 November 2015 (UTC)

Good question. If it is global, then this should be on meta, and not here. If it isn't, it is... not so effective.--Müdigkeit (talk) 15:59, 5 November 2015 (UTC)

I think this question is would be valid if all editors would be subject to being checked. But I think the chances of an account being created on another project, then SUL creating accounts and THEN becoming an admin or functionary are small. It all depends on who will be subject to these password checks. Liz ^{Read! Talk!} 16:12, 5 November 2015 (UTC)

As a matter of fact, there are a lot of SULs with the main account being hosted on another project, but they also have significant user rights here. epic genius (talk) 16:29, 5 November 2015 (UTC)

To give an example, my SUL's main account is hosted on Meta. However, now everything has been centralized.--Ymblanter (talk) 17:59, 5 November 2015 (UTC)

We are perfectly in a position to decide that en/wp functionnaries/admins/whoever are required to have a strong password. I do not see how this affects other projects (unless until they prohibit users to have a strong password).--Ymblanter (talk) 19:17, 5 November 2015 (UTC)

True, but English Wikipedia accounts aren't limited to that project, mainly because of SUL. epic genius (talk) 20:17, 5 November 2015 (UTC)

@Epicgenius: - I was told that whatever policy we put in place would be for logging on to en.wp only. It can be bypassed by logging on at a different project. That is why I will be putting forward the meta equivalent soon. I wanted to have some idea of expectations before I went over there though. Worm^TT(talk) 08:43, 6 November 2015 (UTC)

Why was the so-called "two key" login solution not included as an option here? --IJBall (contribs • talk) 17:24, 5 November 2015 (UTC)

2FA was probably not included because some editors don't necessarily have phone numbers or emails handy, or do not wish to give them. (If we forced people to give an email address or phone number, though, there would be fewer vandals and single-purpose accounts. Another good thing! ) epic genius (talk) 17:29, 5 November 2015 (UTC)

If you look at the top of the page, it seems Worm has plans to open a discussion at meta as well, and I presume that would include the possibility of 2FA on all WMF sites. Since we just had an incident here, it makes sense for us to also discuss some local policy changes rather than wait forever for a process involving meta and the back office to produce results. (Is that about right Worm?) Beeblebrox (talk) 19:11, 5 November 2015 (UTC)

@Beeblebrox, IJBall, and Epicgenius: Not quite. 2FA is something I'd really want to see, but it's also a solution which requires a bit more work from the foundation developers. I'm going to be pushing for it, but the solutions I've offered above are "quick wins" which can be implemented very easily, and more critically which already have someone lined up to do. Whatever we decide can and will be done. I do intend to start a discussion at meta regarding global rights and rights on all projects. Worm^TT(talk) 08:15, 6 November 2015 (UTC)

If you are going to do it on all Admin accounts, you need a way to deal with inactive Admins who don't respond - especially if they don't have email. Doug Weller (talk) 18:42, 5 November 2015 (UTC)

I think 2FA is the only way to go as far as security is concerned. However to your point of not everyone having phone numbers, I think 2FA would only be a requirement for admins and an option for everyone else. Most people have a second device these days and it just has to be able to receive text. A huge win in security, especially since Wikipedia will leave you logged in for two weeks at a time so it isn't much of an inconvenient either. Opencooper (talk) 08:16, 16 November 2015 (UTC)

• I don't know how much credence to give these comments, but someone pointed me in the direction of this discussion thread from an individual who sounds like he was the one who compromised the accounts. Take it for what it's worth. Liz ^{Read! Talk!} 18:52, 5 November 2015 (UTC)

• This doesn't make sense as an English Wikipedia-only discussion. All accounts are global, so any password requirements need to be enforced globally. Legoktm (talk) 19:56, 5 November 2015 (UTC)

Hear, hear. I don't see what would stop us at English Wikipedia from putting it in our guidelines that all administrators need reasonably strong (and unique!) passwords, but when we're talking about technical solutions, this should really be a discussion that involves other Wikimedia communities as well. /Julle (talk) 10:29, 10 November 2015 (UTC)

• One of my IRC buddies who frequents r/WikiInAction directed me to this page. I feel that since Wikipedia labels itself the "sum of all human knowledge", why keep the knowledge of good passwords to ourselves? WP should be a role model, leading by example of good security practices. --DSA510 Pls No Bully 06:02, 6 November 2015 (UTC)

• Just an FYI - Under UK data protection (and probably EU) law, deliberately trying to breach a users account is criminal under almost all circumstances (there are a few exceptions, and 'just checking if their password is safe' is not one of them.) Any UK based registered user would be entitled to report such attempts to the authorities, which would not end well given the number of advanced permissions users in the UK. Not to mention Jimbo is a UK resident now. That data is in the US on the WMF's servers is irrelevent. UK law extends to all UK residents and UK citizens. Any actions taken that would be illegal in the UK, taken in the UK, despite that the data itself is overseas can (and have been in the past) prosecuted. I would highly suggest contacting WMF Legal before even thinking about attempting any sort of brute-force approach to password verifibility.

To be clear: Even if the WMF sanctioned it, it would be illegal under UK law except in strict circumstances. Organisations are not allowed to break their users passwords. While the WMF owns the servers and the data, UK (and EU) law works on the basis that the account is ultimately owned by the end-user. This is why companies/organisations can reset passwords etc, but are not allowed to see what they are. With publically published leaks of user data, the process to be compliant with UK data protection is to lock the account straight away and force a reset. NOT access the account - as that would be a criminal act. Think of the handling stolen goods comparison, you didnt steal the password yourself, but you have taken advantage of it. Only in death does duty end (talk) 10:24, 6 November 2015 (UTC)

If, instead of thinking "outside the box" one thinks "inside the box" this need not be a problem.  ::The classic hacker cracks passwords to find out what the password is. We do not need to know that.

Were I to implement the proposed solution for the WMF (as well as being run in the US, under supervision, and ideally live-steamed!) it would simply indicate the names of the accounts with weak passwords, and not record what the passwords are.

All the best: Rich Farmbrough, 14:41, 6 November 2015 (UTC).

Quite a few modern data laws (as well as internal organisation policies) prevent even the attempt except under strict exceptions on a case by case basis - mainly due to the huge potential for abuse. For example even compiling a list of accounts with weak passwords is an immediate security concern - as the list itself would be unlikely to be encrypted/hashed and then anyone with access to it has a ready made shopping list of people to target. Only in death does duty end (talk) 15:49, 6 November 2015 (UTC)

Much of this is inaccurate. Users provide their cleartext password to the WMF every time they log in. What the WMF do with that password is governed by best practice not any data protection legislation. Whilst trying to crack password hashes under their control might be a slight grey area (though I doubt it very much) the WMF could easily circumvent this by applying a check during the login process, prior to hashing the cleartext. Were your comments accurate then any company which applied a password security/complexity check to their login or signup process would stand in violation of DP legislation. This is patently false. Also; WMF servers are located in the US as is the Corp. so broadly US rules apply (forcing UK data protection rules on the US is notoriously hard). However, I agree that any user attempting to crack passwords or compile lists of unsafe accounts would almost certainly be in violation both of local legislation against such things and the WMF's own terms of use - so we shouldn't attempt it. --Errant ^(chat!) 10:52, 10 November 2015 (UTC)

• Also adding my thanks to Dave (WTT). Two comments which are not listed as options, and I think should be: (As I am forced to log in every 30 days anyway): 1) The always popular "answer the secret question" option. and 2) A forced password reset. Perhaps not for ALL users, but at least Admin, employees, functionaries, etc. — Ched :  ?  10:39, 6 November 2015 (UTC)

• An extra suggestion: as part of the RFA process, new admins should be required to declare that they have a strong password which is not and never has been used on any other site. JohnCD (talk) 22:32, 6 November 2015 (UTC)
• I'm just going to point out that while you're probably going to convince us based on editor consensus, "Adding rules to passwords [...] requires community consensus to implement." in the "Current position" section is not strictly correct. It is subject to the decisions of MediaWiki developers and Wikimedia system administrators (and of course, ultimately the foundation, since they own the servers). I don't think an enwiki-specific policy can technically work due to SUL. --Krenair ^{(talk • contribs)} 02:12, 7 November 2015 (UTC)

Sortof. There are two ways we can implement password policies. When the password doesn't comply with the policy, we can either prevent them from logging in at all, or we can log them in but send them directly to the change password form. In the later case, the user still has the option of clicking "cancel", and continuing on with their work, but the hope is that by prompting the user each time they login, they will have incentive to set a compliant password. In this case, we can set a normal password policy just on enwiki, and admins who login on enwiki will be prompted to set a password in compliance with the policy. They can click cancel, or login on other wikis and rely on SUL to login to enwiki, but the majority will likely know that they are out of compliance. If, instead, we want to lock out all admins with passwords that don't comply, then correct, this would need to be implemented across wikis. In that case, the patch would use the PasswordPoliciesForUser hook, and apply the policy for any enwiki admins, much like we do for global groups in CentralAuth. Separately, I would very much like to see all sysops on all wikis adopt some policies like the ones done here (that conversation probably needs to happen on meta, along with the 2FA discussion), but I would (personally) be uncomfortable rolling that out without consultation. CSteipp (WMF) (talk) 21:44, 7 November 2015 (UTC)

• I'm with Legoktm on this, this is not an enwiki issue, its a global one and should be dealt on meta, and also regarding the "hack", again, Wikipedia was "NEVER" hacked so even if we give every admin a 128-character password, if they use the same password on another site which gets hacked, the hackers will just use that password to edit wikipedia, it makes no sense to create another level of "security" when basically the chances of anyone being able to hack mediawiki wikis and gaining access to everyone password is 0%..Currently we have 44.3m registered global accounts, atleast 35m of those may have a very weak passwords, and maybe a few million of them may have the password as "password" or "12345" but that doesn't mean we create a "new" level of security which may actually become a "Pain in the backside" not only for the developers but also for "newly" registering users who will find it hard to remember passwords which may need to be long and having different characters on them....This is a non-issue, nothing needs to come out of this expect a central notice banner asking (requesting) users to update their passwords and make them stronger..nothing more.--Stemoc 06:26, 8 November 2015 (UTC)
  • Re: "Wikipedia was "NEVER" hacked" - well, not in these two instances and not in any other instance that we know of. Here's hoping your statement is true in an absolute sense, but it's something we will never really know for sure, isn't it? davidwr/(talk)/(contribs) 22:06, 8 November 2015 (UTC)

You're assuming the 128 character password will become known. In reality a 128 character password is unlikely to be compromised provided the site uses some slightly decent hash and isn't compromised over a long period of time (so people are able to monitor passwords during login). See my comments above and below. Nil Einne (talk) 23:07, 12 November 2015 (UTC)

• All the complexity stuff is good but really none of it solves what happened which is password reuse. Any solution that can't address that is a solution in search of a problem. Similarly, all the attempts to defeat cracking software miss the point that the Wikimedia password file wasn't cracked. In fact a lot of the ideas about "auditing passwords" exposes the password file. Ft. Knox doesn't protect the gold by opening the vault 3 times a day to count all the gold - they restrict access to the gold. The password file should be locked, audited for access and not used as the basis for crack programs. Accounts don't need more letter or words, they need "try limits" (i.e. five failed attempts and account is locked). No amount of bytes, special characters or audits will defeat a person that has the correct clear text password. The only way to get that is from either another site or Wikimedia's password file. Protect the password file so access is logged, expire passwords after 90 days, have limited logon attempts. --DHeyward (talk) 23:27, 10 November 2015 (UTC)
  • Expiring passwords after 90 days leads to people having to remember an increasingly large number of passwords. The result is often either weak passwords (to make them easier to remember) or password reuse across sites (to reduce the number of passwords remembered), which is exactly what caused this RfC. --RexxS (talk) 18:03, 12 November 2015 (UTC)

Complexity does actually help against password reuse anyway. See my comment above related to 16 character passwords. If a database is compromised and was plain text or instantly reversable, then any attackers will already have plain text passwords. But many of the worst known examples in recent years haven't been that bad. The most common problem is that have a weak but not super weak hash like MD5. Attackers still need to figure out the password and so complexity is a big factor in whether or not the plain text password becomes known from the database. Yes it would be good if people didn't reuse passwords but for various reasons that's going to happen although we probably should require it for advanced permissions.

Also, AFAIK non of the major incidents were in any way related to internal security audits. Properly protecting the database is essential, but I see no reason why this would prevent an internal audit of passwords. Wikimedia should have protections against external brute forcing (which I think they already do) although as I said above, external brute forcing is only limited utility. But locking a password after 5 failed tries is a good way to help trolls annoy the heck out of editors, remember user account names are public here. 5 failed tries for one account also doesn't help against non targetted attacks.

90 days is complicated and this is one area where I partly agree with DHeywar) and partly disagree with RexxS. It can actually be a resonable advantage. Presuming the person is already reusing, which most people surely are, then even with a weaker password it may help. If another site is compromised, the weaker password may mean it's more likely the plain text will become known which is a major disadvantage. On the flipside, after 90 days the password is going to change. So if the password would have been compromised anyway, provide the added complexity isn't extremely low it may be this isn't useful for long, or never depending on how long it takes to recover the password and when you get access to the database. For example, if someone's password is Br7DM1115 then may be even an automated system will try Br7DM0216 in a few months time. Or if it's a manual attack and you see the password is cat, perhaps you'll try kitten or dog. (Even better if their password is compromised twice and once it was monkey, the next time rhino.) There is actually an advantage even here, since an automated attack (probably not so likely to hit wikipedia) will probably not pick up such things since while it's not that hard to target, there are many other possible patterns so it's not so easy. If there is no pattern and the person just makes the effort to memorise e.g. a 5 character random password every 90 days then this is probably going to be better than in many reuse scenarios. (The alternative is a very complex password such that a hashed password isn't going to become known, although in that case there is still the minor risk of an unhashed password or some other methods of it being compromised.) However I don't think any of this is actually that likely in a reuse environment. For starters, no one is likely to change to follow us, so we'll be one of the few websites who are forcing it. Second, if everyone did do 90 days, this doesn't actually help reusers much since they have the scenario where they haven't used the account in 160 days and can't remember what the password was, and there's no way they're going to change all 100 of their accounts every 90 days intentionally. Really expecting the password to be compromised is your best bet, hence 2FA.

Nil Einne (talk) 23:10, 12 November 2015 (UTC)

In addition to the above, requiring a long password is a countermeasure against password reuse in another way. If a foolish Wikipedia administrator uses the same 8-character password everywhere else and we require a 16-character password (and reject doubleddoubled passworspasswords) then he won't be reusing that password on Wikipedia. --Guy Macon (talk) 17:58, 21 November 2015 (UTC)

• These issues can't be looked at in isolation, but as part of a larger picture. Maybe the following steps:
  1. Asking WMF to get professional development in the security area for appropriate staffers outside the security team (see https://www.mediawiki.org/wiki/Wikimedia_Security_Team for the staffers with (presumably) security as a core competency).
  2. Asking WMF to engage an external party to conduct a security review of passwords and related issues in the wiki infrastructure.
  3. Asking WMF to engage an external party to conduct a security review of media wiki software.
  4. Reviewing wording around security on our pages related to users getting elevated privileges (i.e. check that we're requesting people consider updating their password to something more secure when asking for extra privileges).
  5. Generating and promoting training materials around security that are specifically tailored for the wiki way of working.
  6. Giving parties (particularly more technologically advanced users, such as bots and bot operators) the option of client certificates in addition to passwords.

See also https://www.mediawiki.org/wiki/Wikimedia_Security_Team/Goals_201516 Stuartyeates (talk) 21:58, 15 November 2015 (UTC)

---

Unwarranted Assumption

All of the above questions assume that a user will use a password and not a passphrase. Consider the following:

Password:Zf5:KiF$

Passphrase: if you plan on doing a hot tap you should hire a steamfitter not a pipefitter

There are some tricks you can do with hashes that purposely take a long time per guess, but a fairly inexpensive system (see references below) can crack the above password in less than six hours if it is used on any Windows system since Server 2003. But hey, it passes your case requirement, numerical requirement, and symbol requirement! So there is that.

The above passphrase will take longer than the age of the universe to crack even for a computer millions of times faster than today's fastest supercomputer. Brute Force or Dictionary attack makes no difference: you will die of old age long before it tries 1% of the possible combinations. and it does so while failing your case requirement, numerical requirement, and symbol requirement...

Now try memorizing each one...

We should have a tutorial for creating easy-to-remember, unique and lengthy passphrases, and our requirements should be 32 characters minimum and six words minimum separated by spaces.

• http://blog.codinghorror.com/passwords-vs-pass-phrases/
• http://security.stackexchange.com/questions/6095/xkcd-936-short-complex-password-or-long-dictionary-passphrase
• https://www.netsparker.com/blog/web-security/passwords-pass-phrases-ideological-divide/
• http://arstechnica.com/security/2012/08/passwords-under-assault/
• http://arstechnica.com/security/2012/12/25-gpu-cluster-cracks-every-standard-windows-password-in-6-hours/

--Guy Macon (talk) 01:38, 16 November 2015 (UTC)

Guy is exactly right on this point and the value of having an easily remembered passphrase can't be emphasised enough, because it reduces the temptation to re-use and simplify. It's possible to reduce length (and hence the amount of typing) by including a word that won't be in any dictionary, such as an uncommon name. "Guy Macon's passphrase is secure" is only 32 characters and 5 words, but I would suggest that it would resist cracking almost as well as the pipefitter passphrase. --RexxS (talk) 16:11, 16 November 2015 (UTC)

Essentially correct, but the example "Guy Macon's passphrase is secure" does not include a word that won't be in any dictionary. Besides the fact that "Guy" and "Macon" both have Wikipedia pages, a good cracking dictionary has a huge number of common and uncommon names, and you have to assume that whoever is attacking you has indexed your hard hard drive, including deleted files, and added every printable string to the dictionary, and that they have done the same with your emails, Wikipedia history, tweets, facebook posts, etc.[5] If you want to shorten your passphrase with a word that isn't in any cracking dictionary, it should be a random word that has nothing to do with anything. Something like Korwyann, Lijmimat, Doutkahi, Vackmiur, Cheazfaj, Wilabipa, or Idoxryda. www.google.com/search?q=random+pronounceable+words has a bunch of programs for generating random pronounceable words. --Guy Macon (talk) 19:47, 17 November 2015 (UTC)

Indeed you're right, any word might be in a dictionary, so the question is how much effort can we expect a cracker to expend on coding different types of dictionary attacks? If we make our passwords unique - so that if "Guy Macon's passphrase is secure" were my passphrase only on the Wikipedia site - who is going to bother burgling my house and trying to index my (encrypted) hard drive, just to access my Wikipedia account? I like the idea of pronounceable words as they are easier to remember, but even a single short non-word like "qxgfe" can disrupt most dictionary attacks and some people might find it as easy to remember. --RexxS (talk) 18:15, 18 November 2015 (UTC)

Long passphrases have a problem in traditional entry fields: you can't see when you've made a typo. I use a 40-character passphrase for one of my logins, and I've got about a 20% failure rate at logging in. --Carnildo (talk) 02:42, 17 November 2015 (UTC)

This is why a well-designed passphrase entry screen has a checkbox that allows the user to see the passphrase they are entering. Veracrypt, for example, does this. Dispaying "********" is pretty much just security theater; anyone in a position to see what is on your screen is likely to be in a position to watch your fingers as you type in the passphrase. --Guy Macon (talk) 18:55, 17 November 2015 (UTC)

Brute force is only on vector for attack. Whilst this approach is good, when used appropriately, people will tend to choose phrases which are phrases, often from a limited dictionary set, not uncommonly from famous or known works. Attacks have, necessarily, evolved to attack such approaches. As I've mentioned before this is not about those who can choose well-fromed passwords. If you specify complex requirements, or insist on using phrases, those people with secure passwords will continue to use secure passwords. The problem are those who have a lower level of password security. And so we are looking, again, at the wrong question: we should be looking for ways to increase the overall average password complexity amongst our users. This is a popular suggestion (passphrase) but it, unfortunately, has the same flaws as some of the other suggestions it casts as wrong. --Errant ^(chat!) 20:31, 17 November 2015 (UTC)

• I am just going to leave this here: http://basicinstructions.net/basic-instructions/2015/11/17/how-to-pick-a-password.html --Guy Macon (talk) 01:12, 18 November 2015 (UTC)
  • Well yes, my point exactly. --Errant ^(chat!) 07:32, 18 November 2015 (UTC)
    • Security is always going to be a trade-off between strength and usability. Increasing the pool of characters used in a password does much less to counter brute-force attacks than increasing the length. This can be seen easily by examining the number of permutations of L characters from a pool of S - which is simply S^L. Doubling the pool to 2S characters increases the number of permutations by a factor of 2^L, while doubling the length increases the number by a factor of S^L. The problem we face is that of peoples' ability to remember - my password manager keeps track of over 200 website passwords for me. The value of passphrases is that they represent a massive increase in strength against brute force attacks while remaining memorable and can be hardened against dictionary attacks with much less effect on memorability, for example by including one non-word in a string of four or five words. Given the number of sites where we have to logon these days, I firmly believe that the biggest threat we face comes from password re-use, and anything done to make it easier to remember passwords is a big gain in encouraging folks to make them unique. That's where the real advantage of passphrases lies. --RexxS (talk) 17:46, 18 November 2015 (UTC)
      • The value of passphrases is that they represent a massive increase in strength against brute force attacks ; not true. It increases the theoretical strength of passwords. However the use of discrete words, in the form of a sentence, pretty much negates that immediately. All of which doesn't address the central tenet of the problem: it doesn't make people pick more secure passphrases (because even at, say, 20 characters, it's easy to pick a poor passphrase). We should: encourage people to use password managers (which helps to fix the problem of password reuse) and implement 2 factor auth for people with advanced permissions (which is the best and recommended method of additional security, over password complexity requirements). --Errant ^(chat!) 19:17, 18 November 2015 (UTC)
        • It almost certainly is true, assuming we can agree on what we mean by "brute-force attack". According to Wikipedia, that is "... an application of brute-force search, the general problem-solving technique of enumerating all candidates and checking each one." It's irrelevant to a brute force attack against a stolen hash table whether a 20 character password consists of random alphabetical characters or recognisable words, so I stand by my original assertion. I unequivocally accept that changing from a brute force attack to a dictionary attack will be far quicker to crack a passphrase consisting of recognisable words, but it's not difficult to harden a passphrase so that it is still easily rememorable while remaining far stronger than any rememorable set of random characters. And it's the problem of memorability that we use it to solve. I do agree totally that using a password manager that provides an unique password for each site and 2FA to access crucial information are better solutions (it's what I do myself), but I know of no way to encourage Wikipedia editors to pick those options. I do know that it's not so difficult to encourage them to swap from "01/04/2000" or "Password1!" to "9 out of 10 editors omkc Jimbo." --RexxS (talk) 23:34, 18 November 2015 (UTC)
          • Using a password manager will probably increase the chance of a family member hacking into the account; and is only practical if the user has his/her own private computer (or computer user account) to store it on. And Wikipedia has protection against brute-force attacks - you have 3 tries which a computer could use unaided, and 3-4 more which a human being could do, and then you need to wait 15 minutes to try again from the same IP address. Unless the computer can scroll through over a hundred IP addresses, it can't even reach a level of 6 tries a minute, averaged over an hour. עוד מישהו Od Mishehu 15:29, 19 November 2015 (UTC)
            • Every password manager I know of uses a password to protect the other passwords. That's the point; you only have to remember one. Also, we should not rely upon Wikipedia's protection against brute-force attacks. Doing so violates Kerckhoffs's principle. Related: Security through obscurity. --Guy Macon (talk) 18:26, 19 November 2015 (UTC)
              • @Od Mishehu: Who would try to brute-force a password directly on a website? The slowness of the servers would defeat most attacks even without any lockout. What happens is that the list of hashed passwords is stolen and the hacker uses brute-force on that at 348 billion hashes per second. So, if it's okay with you, I'll keep my password manager that lets me use a different 20-character random password on each site, which will take even that setup over 65 thousand million million years to crack. YMMV --RexxS (talk) 01:43, 20 November 2015 (UTC)
                • Exactly right. RexxS is approaching security the right way. And if anyone thinks that Wikipedia's list of hashed passwords will never be stolen, they are relying on the discredited idea of Security through obscurity. --Guy Macon (talk) 23:38, 20 November 2015 (UTC)
                  • Its important to consider threats of different levels and take the threat in context. Yes the offline brute force attacker is important to defend against and a major threat. But that doesn't mean online attackers are irrelevant. Taken to extremes, that logic leads to the conclusion that we should just give up, as a sufficiently sophisticated attacker might be launching a MitM attack from the internet backbone, with a compromised CA and there's nothing we can do about that [however it should be noted, that our max password attempts thingy isn't actually a very good limiter for the online attack case]. Bawolff (talk) 22:22, 7 December 2015 (UTC)

---

• Look at the bottom comic strip here:[6] --Guy Macon (talk) 23:38, 20 November 2015 (UTC)

---

In addition to regular audits for the functionaries and administrators, I'm proposing that we allow any user (or any user with special rights) opt-in to the security audit. Zhaofeng Li [talk ♦ contribs] 11:43, 22 November 2015 (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.