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.
Contents
- 1 Current position
- 2 Suggestions
- 2.1 Status quo
- 2.1.1 Discussion
- 2.1.2 Length increase to 6 bytes
- 2.1.3 Length increase to 8 bytes
- 2.1.4 Length increase to 16 bytes
- 2.1.5 Comment
- 2.1.6 Case requirements
- 2.1.7 Numerical requirements
- 2.1.8 Symbol requirements
- 2.1.9 Uncommon passwords
- 2.1.10 Complexity requirement
- 2.1.11 Add a password strength bar to the "Create account" page
- 2.1.12 Email editors if their email address was included in a breach
- 2.2 User groups to apply password requirement to
- 2.2.1 Password requirements for Crats, Stewards and Founder groups
- 2.2.2 Password requirements for Functionary group
- 2.2.3 Password requirements for Administrator group
- 2.2.4 Password requirements for Edit Filter Manager group
- 2.2.5 Password requirements for Template Editor group
- 2.2.6 Password requirements for users with AutoWikiBrowser access
- 2.2.7 Password requirements for All users
- 2.3 Regular auditing
- 2.4 General discussion
- 2.1 Status quo
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
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
- 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)
- 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)
- Oppose Status Quo
- I believe that the status quo is not acceptable. WormTT(talk) 10:47, 5 November 2015 (UTC)
- I agree. Callanecc (talk • contribs • logs) 11:18, 5 November 2015 (UTC)
- Agreed. --Dweller (talk) 11:21, 5 November 2015 (UTC)
- Sam Walton (talk) 12:06, 5 November 2015 (UTC)
- The situation we recently experienced shows this does not appear to be a suitable option. Amortias (T)(C) 12:29, 5 November 2015 (UTC)
- 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)
- 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)
- 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)
- Too dangerous--Ymblanter (talk) 17:49, 5 November 2015 (UTC)
- Agree with all above. BMK (talk) 18:29, 5 November 2015 (UTC)
- BethNaught (talk) 19:24, 5 November 2015 (UTC)
- The password should be longer than one byte. -- GB fan 19:52, 5 November 2015 (UTC)
- Common sense and the recent experience show something is needed. Johnuniq (talk) 00:53, 6 November 2015 (UTC)
- It isn't acceptable. If not better password requirements, we need 2FA. LorTalk 01:15, 6 November 2015 (UTC)
- This is going to keep happening if we don't do something. — Earwig talk 09:03, 6 November 2015 (UTC)
- — Ched : ? 10:07, 6 November 2015 (UTC)
- One byte? Seriously? MER-C 17:35, 6 November 2015 (UTC)
- JohnCD (talk) 22:17, 6 November 2015 (UTC)
- After that disaster we need to make the Passwords better otherwise this could happen again and again. –Davey2010Talk 04:31, 10 November 2015 (UTC)
- No, the status quo is entirely inadequate. —DoRD (talk) 01:10, 11 November 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. WormTT(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)
- What definition of "bit" is being used here? Do you mean "byte"? 68.97.47.54 (talk) 13:12, 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
- What is the overlap area between acceptable difficulty for the user and acceptable security for that class of access, if any, and
- 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).
Length increase to 6 bytes
The minimum length of a password should be increased from 1 byte to 6 bytes.
- Support Length increase to 6 bytes
- But prefer 8 bits. WormTT(talk) 10:47, 5 November 2015 (UTC)
- Yep. Callanecc (talk • contribs • logs) 11:19, 5 November 2015 (UTC)
- Support. POV alert, but this fits my ideas of common sense. --Dweller (talk) 11:22, 5 November 2015 (UTC)
- 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)
- At a minimum. --kelapstick(bainuu) 17:25, 5 November 2015 (UTC)
- Sounds reasonable--Ymblanter (talk) 17:49, 5 November 2015 (UTC)
- Second choice to 8 bytes. BethNaught (talk) 19:24, 5 November 2015 (UTC)
- 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).
- Would you compromise on seven? All the best: Rich Farmbrough, 14:03, 6 November 2015 (UTC).
- 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)
- Minimum. JohnCD (talk) 22:18, 6 November 2015 (UTC)
- Okay. Risker (talk) 05:48, 7 November 2015 (UTC)
- 6 or 8 seem reasonable. Mkdwtalk 22:26, 7 November 2015 (UTC)
- Oppose Length increase to 6 bytes
- 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)
Length increase to 8 bytes
The minimum length of a password should be increased from 1 byte to 8 bytes.
- Support Length increase to 8 bytes
- For preference WormTT(talk) 10:47, 5 November 2015 (UTC)
- Support While no password is truly uncrackable, the longer the password, the harder it is to crack KoshVorlon 11:46, 5 November 2015 (UTC)
- 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)
- 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)
- 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)
- 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)
- 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 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)
- Pretty good requirement. APerson (talk!) 14:15, 6 November 2015 (UTC)
- Looks like a basic and simple way to improve security. Rcsprinter123 (sing) 14:32, 6 November 2015 (UTC)
- 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)
- Adequate. JohnCD (talk) 22:19, 6 November 2015 (UTC)
- Okay. Risker (talk) 05:49, 7 November 2015 (UTC)
- 6 or 8 seem reasonable. Mkdwtalk 22:26, 7 November 2015 (UTC)
- 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)
- Unless everyone wants there account hacked then it's probably a good idea to make it longer & harder to guess... –Davey2010Talk 04:38, 10 November 2015 (UTC)
- Oppose Length increase to 8 bytes
- 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).
- Disagree with precept. DoB is not a "complex password". All the best: Rich Farmbrough, 14:04, 6 November 2015 (UTC).
- 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)
Length increase to 16 bytes
The minimum length of a password should be increased from 1 byte to 16 bytes.
- Support Length increase to 16 bytes
- Per this. sst✈discuss 13:44, 5 November 2015 (UTC)
- 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)
- 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)
- Oppose Length increase to 16 bytes
- 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)
- 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)
- I've yet to decide on 6 or 8 characters, but 16 is certainly overkill. Sam Walton (talk) 15:38, 5 November 2015 (UTC)
- Overkill. Coming up with a secure password of this length would in itself deter sign-ups. BethNaught (talk) 19:24, 5 November 2015 (UTC)
- No need for a password this long. -- GB fan 20:13, 5 November 2015 (UTC)
- 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)
- 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)
- Too much. JohnCD (talk) 22:19, 6 November 2015 (UTC)
- People won't remember their passwords. Mkdwtalk 22:21, 7 November 2015 (UTC)
- Still too short!, Make it 87 that should do it. –Davey2010Talk 04:40, 10 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).
Case requirements
A password should require at least 1 uppercase and 1 lowercase letter.
- Support Case requirements
- I would support this requirement. WormTT(talk) 10:47, 5 November 2015 (UTC)
- 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)
- 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)
- 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) - 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)
- Oppose Case requirements
- 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)
- 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)
- 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. WormTT(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).
- well, yes, but not this- because of language.--Müdigkeit (talk) 11:56, 5 November 2015 (UTC)
- Per the above reasons; length is more important than this. Sam Walton (talk) 12:07, 5 November 2015 (UTC)
- Many users use non-latin passwords. Forcing different cases does not enhance security much anyway. sst✈discuss 13:42, 5 November 2015 (UTC)
- 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)
- 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).
- 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)
- Passwords do not need character type requirements to be secure: see Diceware. BethNaught (talk) 19:24, 5 November 2015 (UTC)
- See my answer below. But this has a worse effect. All the best: Rich Farmbrough, 20:05, 5 November 2015 (UTC).
- 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)
- 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)
- 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)
- 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)
- Per above. JohnCD (talk) 22:21, 6 November 2015 (UTC)
- 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)
- 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. –Davey2010Talk 04:45, 10 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)
Numerical requirements
A password should require at least one numerical character - i.e. 0-9
- Support Numerical requirements
- I would support this requirement. WormTT(talk) 10:47, 5 November 2015 (UTC)
- Support per the statement I made above KoshVorlon 11:48, 5 November 2015 (UTC)
- 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)
- Atleast to me it's common sense to have a number on the end anyway..... –Davey2010Talk 04:50, 10 November 2015 (UTC)
- Oppose Numerical requirements
- 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)
- Not effective. sst✈discuss 13:48, 5 November 2015 (UTC)
- 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)
- I agree, this is not an effective deterrent. Beeblebrox (talk) 18:51, 5 November 2015 (UTC)
- Passwords do not need character type requirements to be secure: see Diceware. BethNaught (talk) 19:24, 5 November 2015 (UTC)
- 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).
- 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)
- 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)
- Oppose per above section. — Earwig talk 09:03, 6 November 2015 (UTC)
- Oppose per above. JohnCD (talk) 22:22, 6 November 2015 (UTC)
- What Rich said.. Risker (talk) 05:50, 7 November 2015 (UTC)
Symbol requirements
A password should require at least one symbol.
- Support Symbol requirements
- I would support this requirement WormTT(talk) 10:47, 5 November 2015 (UTC)
- 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. WormTT(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).
- 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).
- 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)
- I sincerely hope that passwords are stored encrypted, so this shouldn't be a problem. Will check though. WormTT(talk) 11:53, 5 November 2015 (UTC)
- 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)
- Oppose Symbol requirements
- 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)
- 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)
- Per Risker. sst✈discuss 13:50, 5 November 2015 (UTC)
- 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)
- Again, not an effective deterrent. Beeblebrox (talk) 18:52, 5 November 2015 (UTC)
- Passwords do not need character type requirements to be secure: see Diceware. BethNaught (talk) 19:24, 5 November 2015 (UTC)
- 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)
- 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)
- Oppose this one especially. — Earwig talk 09:03, 6 November 2015 (UTC)
- Oppose per above. JohnCD (talk) 22:23, 6 November 2015 (UTC)
- 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)
- I too oppose this one especially. Per all above. Fylbecatulous talk 16:23, 8 November 2015 (UTC)
- .... 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. –Davey2010Talk 04:52, 10 November 2015 (UTC)
Uncommon passwords
A password should not be in the list of the 10,000 most common passwords.
- Support Uncommon passwords
- I would support this requirement. WormTT(talk) 10:47, 5 November 2015 (UTC)
- This is a cheap way of preventing dictionary attacks. --Carnildo (talk) 02:43, 6 November 2015 (UTC)
- 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)
- Sounds like a good idea. APerson (talk!) 14:17, 6 November 2015 (UTC)
- 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)
- Oppose Uncommon passwords
- I'm tentatively here, I think 10,000 is probably overkill. Callanecc (talk • contribs • logs) 11:18, 5 November 2015 (UTC)
- 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)
- 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)
- Commonsense should apply .... If someone wants to create a password like "Banana1" then they should knock themselves out,,,, literally!. –Davey2010Talk 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. WormTT(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 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)
- 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).
- 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)
Complexity requirement
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
- 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)
- Tentative support depending on implementation details. DES (talk) 01:37, 6 November 2015 (UTC)
- 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)
- Oppose Complexity requirement
- 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)
- 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).
- All the best: Rich Farmbrough, 14:24, 7 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)
Add a password strength bar to the "Create account" page
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
- Proposing this so new users could know whether their password is secure. epic genius (talk) 16:25, 5 November 2015 (UTC)
- 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).
- 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).
- Support. All the best: Rich Farmbrough, 19:42, 5 November 2015 (UTC).
- Effective and lets the user decide the risk he or she wants to take. sst✈discuss 04:50, 6 November 2015 (UTC)
- Support The more incentives for having a good password, the better. --DSA510 Pls No Bully 05:52, 6 November 2015 (UTC)
- 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)
- Conditional on a competent implementation. MER-C 19:39, 6 November 2015 (UTC)
- 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)
- Pretty much the norm on every website these days, Would really make sense to have one here aswell. –Davey2010Talk 04:58, 10 November 2015 (UTC)
- Oppose Add a password strength bar
- 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)
- 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)
Email editors if their email address was included in a breach
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)
User groups to apply password requirement to
Password requirements for Crats, Stewards and Founder groups
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
- 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).
- For 'crats. — Earwig talk 09:03, 6 November 2015 (UTC)
- 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)
- Certainly. JohnCD (talk) 22:25, 6 November 2015 (UTC)
- Not sure if we can do anything here but if we can then ofcourse!. –Davey2010Talk 05:01, 10 November 2015 (UTC)
- Oppose Password requirements for 'Crats, Stewards and Founder groups
- Comments Password requirements for 'Crats, Stewards and Founder groups
- 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).
- 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).
- There are no crats or founders that are not admins. I'd prefer we just point it at that group. WormTT(talk) 14:33, 6 November 2015 (UTC)
Password requirements for Functionary group
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
- Definitely WormTT(talk) 10:47, 5 November 2015 (UTC)
- Absolutely. Callanecc (talk • contribs • logs) 11:14, 5 November 2015 (UTC)
- At a minimum, something should be applied. --kelapstick(bainuu) 11:52, 5 November 2015 (UTC)
- Definitely. Sam Walton (talk) 12:09, 5 November 2015 (UTC)
- 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
- With access to the most sensitive data, a stronger password is required. Elockid Message me 13:12, 5 November 2015 (UTC)
- Can't be anything wrong with letting rogue functionaries steal all these data. :p epic genius (talk) 14:22, 5 November 2015 (UTC)
- Yes Hasteur (talk) 15:59, 5 November 2015 (UTC)
- Certainly.--Ymblanter (talk) 17:52, 5 November 2015 (UTC)
- Agree. BMK (talk) 18:31, 5 November 2015 (UTC)
- 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)
- This is essential. BethNaught (talk) 19:24, 5 November 2015 (UTC)
- 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).
- 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)
- Of course. — Earwig talk 09:03, 6 November 2015 (UTC)
- Obviously. MER-C 17:50, 6 November 2015 (UTC)
- Absolutely. JohnCD (talk) 22:25, 6 November 2015 (UTC)
- Mkdwtalk 22:22, 7 November 2015 (UTC)
- Support, certainly. — xaosflux Talk 15:48, 8 November 2015 (UTC)
- As these accounts work with sensitive stuff & whatnot it only makes sense to have a much better password. –Davey2010Talk 05:03, 10 November 2015 (UTC)
- Yes, this would seem to be an obvious necessity. —DoRD (talk) 01:13, 11 November 2015 (UTC)
- Oppose Password requirements for Functionary group
Password requirements for Administrator group
The group of users with the sysop flag (currently 1,330) and therefore the ability to see deleted data - Wikipedia:Administrators
- Support Password requirements for Administrator group
- Definitely WormTT(talk) 10:47, 5 November 2015 (UTC)
- kelapstick(bainuu) 11:55, 5 November 2015 (UTC)
- Not as vitally important as functionaries, but still worth higher security. Sam Walton (talk) 12:09, 5 November 2015 (UTC)
- Per Samwalton9. Amortias (T)(C) 12:30, 5 November 2015 (UTC)
- 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)
- The accounts breached are admins, it makes sense to require strong passwords for all admins. sst✈discuss 13:45, 5 November 2015 (UTC)
- There is the same vulnerability with rogue admins as with functionaries. epic genius (talk) 14:23, 5 November 2015 (UTC)
- I would say so, the risk is too high--Ymblanter (talk) 17:52, 5 November 2015 (UTC)
- Agree. BMK (talk) 18:32, 5 November 2015 (UTC)
- 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)
- 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).
- This only covers one aspect of good security practices. All the best: Rich Farmbrough, 20:29, 5 November 2015 (UTC).
- 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).
- Of course. — Earwig talk 09:03, 6 November 2015 (UTC)
- 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)
- Certainly. JohnCD (talk) 22:26, 6 November 2015 (UTC)
- Mkdwtalk 22:22, 7 November 2015 (UTC)
- Support. — xaosflux Talk 15:46, 8 November 2015 (UTC)
- Ofcourse!. –Davey2010Talk 05:04, 10 November 2015 (UTC)
- This also seems to be a necessary step to take. —DoRD (talk) 01:14, 11 November 2015 (UTC)
- Oppose Password requirements for Administrator group
- 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. WormTT(talk) 08:36, 6 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).
Password requirements for Edit Filter Manager group
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
- 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).
- 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)
- This is another group I'd support any requirements being applied to. WormTT(talk) 08:32, 6 November 2015 (UTC)
- 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)
- 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)
- Oppose Password requirements for Edit Filter Manager group
- Comments Password requirements for Edit Filter Manager group
- 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).
Password requirements for Template Editor group
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
- Yes, there is vandalism leverage, but it is subject to reverts, and blocks. All the best: Rich Farmbrough, 21:01, 5 November 2015 (UTC).
- 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)
- No private data involved; I don't see a strong reason. — Earwig talk 09:03, 6 November 2015 (UTC)
- No point as any template edits can be reverted and the compromised account blocked. –Davey2010Talk 05:06, 10 November 2015 (UTC)
- Comments Password requirements for Template Editor group
Password requirements for users with AutoWikiBrowser access
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
- 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)
- Oppose Password requirements for users with AutoWikiBrowser access
- 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. WormTT(talk) 14:09, 5 November 2015 (UTC)
- 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)
- 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)
- Per others. BethNaught (talk) 19:24, 5 November 2015 (UTC)
- Oppose Because <pre-redacted per WP:BEANS> this does nothing special for security. All the best: Rich Farmbrough, 19:44, 5 November 2015 (UTC).
- 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)
- Oppose, this should be the same as any other user account requirements. — xaosflux Talk 15:48, 8 November 2015 (UTC)
- No point as any AWB edits can be reverted and the account can be blocked. –Davey2010Talk 05:08, 10 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)
Password requirements for All users
All users (currently 26,696,368) should follow these password requirements.
- Support Password requirements for All users
- 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. WormTT(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
- I think that forcing all users to conform to these new requirement is probably overkill. WormTT(talk) 10:47, 5 November 2015 (UTC)
- 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)
- I don't think this is necessary. --kelapstick(bainuu) 11:54, 5 November 2015 (UTC)
- Would hurt editor retention. sst✈discuss 13:44, 5 November 2015 (UTC)
- 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)
- 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)
- 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)
- 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)
- There's no increased security for Wikipedia in this. BMK (talk) 18:29, 5 November 2015 (UTC)
- 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)
- Not necessary for Wikipedia's security. Will deter sign-ups. BethNaught (talk) 19:24, 5 November 2015 (UTC)
- 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).
- No strong reason for this in general. — Earwig talk 09:03, 6 November 2015 (UTC)
- Not necessary. JohnCD (talk) 22:26, 6 November 2015 (UTC)
- 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)
- This would discourage registration and possibly editing altogether. Reach Out to the Truth 18:14, 7 November 2015 (UTC)
- I worry this would complicate the process of editing and steer writers away from the project, especially those without strong computer skills. Mkdwtalk 22:25, 7 November 2015 (UTC)
- 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. –Davey2010Talk 05:14, 10 November 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).
- Yes I'd add EFM and maybe TE. All the best: Rich Farmbrough, 20:36, 5 November 2015 (UTC).
- 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)
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
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
- Definitely. WormTT(talk) 10:47, 5 November 2015 (UTC)
- Support. QuiteUnusual (talk) 11:04, 5 November 2015 (UTC)
- Absolutely. Elockid Message me 13:08, 5 November 2015 (UTC)
- Support this idea. In addition, force a password reset every once in a while. epic genius (talk) 15:39, 5 November 2015 (UTC)
- With details to be figured out.--Ymblanter (talk) 17:55, 5 November 2015 (UTC)
- Agree. BMK (talk) 18:33, 5 November 2015 (UTC)
- Essential. BethNaught (talk) 19:24, 5 November 2015 (UTC)
- Obviously yes. --DSA510 Pls No Bully 05:58, 6 November 2015 (UTC)
- In some form, yes. — Earwig talk 09:03, 6 November 2015 (UTC)
- Buy a bunch of GPUs, install Hashcat and set it loose. MER-C 17:53, 6 November 2015 (UTC)
- Absolutely!. –Davey2010Talk 05:15, 10 November 2015 (UTC)
- 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)
- Oppose Regular audits for Functionary group
- 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).
- 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
- @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. WormTT(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 WormTT(talk) 14:40, 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).
- 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)
- 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)
- 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)
Regular audits for Administrator group
Regular audits for the group of users with the sysop flag (currently 1,330) and therefore the ability to see deleted data - Wikipedia:Administrators
- Support Regular audits for Administrator group
- Definitely. WormTT(talk) 10:47, 5 November 2015 (UTC)
- Support. QuiteUnusual (talk) 11:04, 5 November 2015 (UTC)
- 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).
- Support this idea. In addition, force a password reset every once in a while. epic genius (talk) 15:39, 5 November 2015 (UTC)
- With details to be figured out.--Ymblanter (talk) 17:55, 5 November 2015 (UTC)
- Agree. BMK (talk) 18:33, 5 November 2015 (UTC)
- 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)
- As above. — Earwig talk 09:03, 6 November 2015 (UTC)
- As above. MER-C 17:54, 6 November 2015 (UTC)
- 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)
- Absolutely!. –Davey2010Talk 05:16, 10 November 2015 (UTC)
- As above. —DoRD (talk) 01:19, 11 November 2015 (UTC)
- Oppose Regular audits for Administrator group
- See above. All the best: Rich Farmbrough, 19:53, 5 November 2015 (UTC).
- Not if it gives someone access to the encrypted password file. No one should be running crack on it. No one should be bale 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)
General discussion
- 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. WormTT(talk) 11:09, 5 November 2015 (UTC) - I've updated to focus on CUOS [3] WormTT(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).
- 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)
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)
- 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)
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)
- 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)
- 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. WormTT(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. WormTT(talk) 08:15, 6 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)
- 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 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)
- 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)
- 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)
- 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)