Requests for comment/Password policy for users with certain advanced permissions/es

Outdated translations are marked like this.

The following request for comments is closed. There is clear consensus to implement the proposed change. Users with advanced permissions will be required to have a password of at least 8 bytes, to be implemented by WMF technical staff at a later date. Ajraddatz (talk) 07:24, 22 January 2016 (UTC)[reply]


While its possible to do this on a per-wiki basis, it generally makes more sense to have this be consistent across Wikimedia wikis. This is especially true, as compromising one of these accounts can significantly undermine the security of all Wikimedia wikis.

In particular, a person with the editinterface right, who was knowledgeable about javascript, could potentially take over other users accounts, extract personally identifying information from arbitrary users, or even use Wikimedia sites to serve malicious software to unsuspecting victims. Thus it is critical that accounts with the ability to edit site JS are kept secure.

Propuesta

To that end, we would like to propose that the password requirements be adjusted for users who have the editinterface right (Can edit pages in the MediaWiki namespace, like MediaWiki:Common.js), users who have a right that is subject to Access to nonpublic information policy[1], or users who are allowed to add other users to such groups. Specifically:

The following local groups on all wikis:

  • Administrator
  • Bureaucrat
  • Checkusers
  • Oversight

The following local groups which are only on some wikis:

  • Central Notice Admin (meta and testwiki only)
  • templateeditor (on fa wikipedia and ro wikipedia only. Not for group with same name but different rights on enwiki)
  • botadmin (on frwiktionary and ml language projects only)
  • interface-editor (on wikis where such a right exists)
  • translator (on incubator wiki only)
  • technician (on tr wikipedia only)
  • wikidata-staff (on wikidata only)

And the following global groups:

This proposal does not apply to stewards and staff global groups as discussions with the stewards have already taken place directly, and staff have already had these requirements applied to them.

Should this proposal gain consensus, any new group that is created in the future that has either the editinterface right, or a right associated with oversight or checkuser, will also be subject to these requirements.

The proposed new requirements are:

  • Password must not be in the top 10,000 (after removing case insensitive duplicates) common passwords from the RockYou password corpus [1] (large file). After excluding passwords less than 8 bytes long, there are 3,368 that are banned.
  • Password cannot be the words 'Wiki', 'MediaWiki' or the name of the project in question.
  • Passwords must be at least 8 bytes long (If you do not know what a "byte" is, see FAQ below).

This is in addition to the current requirements, which are:

  • Password must be at least 1 character long.
  • Password cannot be the same as the username.
  1. This does not include people in the OTRS group, as although they are subject to that policy, their wiki account does not grant them access to the restricted data

Preguntas frecuentes

Difference between bits, bytes and characters

Bits, bytes and characters are all units of measurements. For English text, 1 byte = 8 bits = 1 character. For other languages, it can vary depending on the language, so in general: 1 character = 1-4 bytes = 8-32 bits.

Please note, that a bit used in this sense is different from a bit of entropy.

Bits of Entropy

When passwords come up, somebody usually brings up entropy. Entropy is a measure of how random your password is. For example, "123456789" is a much weaker password than "WNTpZQYb", despite the fact that "123456789" is longer. This is because it has more entropy.

Very roughly speaking, you can think of the phrase "X bits of entropy" as meaning the password is as random as picking a number at random (uniformly) between 1 and 2x. So a password with 10 bits of entropy is equivalent to picking a number between 1 and 1024 as your password.

Ideally we would simply require a password has a certain amount of entropy. However in practice, it's very difficult to determine how much entropy a specific password has, as one has no idea what distribution the user picked the password from.

Este comic contiene una explicación fácil de entender del concepto de entropía de contraseñas y como elegir una contraseña con mucha entropía.

Cómo se guardan las contraseñas en los wikis de Wikimedia

Since September 2014, we have been storing passwords using the PBKDF2 hash function, with the underlying hash being HMAC-SHA-256, a cost of 64000 rounds and a 128-bit salt.

Using this method of storing passwords is meant to make it more difficult to brute-force passwords in the event a malicious person managed to obtain the Wikimedia password file. However, that only helps if the user chooses a difficult to guess password, so always use a strong password.

What about 2FA (Two-factor authentication)

Two-factor authentication is a scheme where in addition to requiring a password to log in, you also have an app on your phone that provides a code that changes regularly. In order to log in, you need both your password, and this regularly changing code. The idea is that even if someone knows your password, they would also have to steal your phone (Or infect it with malware, etc), in order to compromise your account.

We currently do not support 2FA on Wikimedia, but would like to in the future. Having a 2FA system that admins can opt in to is one of the quarterly goals of the WMF security team for next quarter[2].

How does this RFC interact with the RFC on English Wikipedia

This RFC is for all of Wikimedia. Should this RFC fail to gain consensus, we will implement the changes to password requirements from the en Wikipedia RFC on en Wikipedia only.

While we would like to have consistent security standards for all admin and higher accounts, as the security of the entire site lies with the security of theses accounts, we can certainly do it on a per-wiki basis if that is the way the consensus leans.

If this passes, what happens to people whose passwords don't meet the requirements

Once the restrictions are put into place, users who don't have a strong enough password will be asked to change it next time they log in. Additionally, users that are in the restricted groups will be prevented from changing their password to a password not meeting the requirements.



Discusión

Support

//meta.wikimedia.org/w/index.php?title=Requests_for_comment/Password_policy_for_users_with_certain_advanced_permissions/support&action=edit
  1. Strong support Strong support Their accounts being compromised will end up with the project vandalized --Skupsum (talk) 14:17, 11 January 2016 (UTC)[reply]
  2. Esquilo (talk) 09:01, 21 December 2015 (UTC) Provided that CrackLib or any other qualified method is used to ensure password strength rather than stupid, rigid rules based on password length and usages of digits, capitals etc.[reply]
  3. --Steinsplitter (talk) 10:57, 13 December 2015 (UTC)[reply]
  4. --Geraki TL 11:09, 13 December 2015 (UTC)[reply]
  5. --Ochilov (talk) 11:42, 13 December 2015 (UTC)[reply]
  6. TheDJ (talkcontribs) 12:05, 13 December 2015 (UTC)[reply]
  7. MarcoAurelio 14:47, 13 December 2015 (UTC)[reply]
  8. It may indeed sound as a message of distrust, but so far no one checked whether accounts with advanced permissions indeed have strong passwords — NickK (talk) 14:57, 13 December 2015 (UTC)[reply]
  9. Helder 16:57, 13 December 2015 (UTC)[reply]
  10. Krenair (talkcontribs) 17:55, 13 December 2015 (UTC)[reply]
  11. LFaraone (talk) 18:55, 13 December 2015 (UTC)[reply]
  12. It may be worthwhile to implement this on all accounts on private wikis too. --Rschen7754 19:31, 13 December 2015 (UTC)[reply]
  13. Antero de Quintal (talk) 20:23, 13 December 2015 (UTC)[reply]
  14. I also agree that we need to add some password policies to all accounts, not just admins and functionaries. Reguyla (talk) 20:25, 13 December 2015 (UTC)[reply]
  15. Those proposed criteria for passwords have been like an unwritten rule for me anyway.--Snaevar (talk) 22:56, 13 December 2015 (UTC)[reply]
  16. --Tgr (talk) 23:03, 13 December 2015 (UTC)[reply]
  17. Platonides (talk) 23:20, 13 December 2015 (UTC)[reply]
  18. --Malatinszky (talk) 23:59, 13 December 2015 (UTC)[reply]
  19. Callanecc (talk) 00:16, 14 December 2015 (UTC)[reply]
  20. -- Mlpearc (open channel) 00:43, 14 December 2015 (UTC)[reply]
  21. Mike VTalk 01:04, 14 December 2015 (UTC)[reply]
  22. For all users, not just those with advanced permissions. Ansh666 (talk) 02:33, 14 December 2015 (UTC)[reply]
  23. — JJMC89(T·C) 03:05, 14 December 2015 (UTC)[reply]
  24. --Lsanabria (talk) 03:58, 14 December 2015 (UTC)[reply]
  25. Absolutely. James F. (talk) 05:06, 14 December 2015 (UTC)[reply]
  26. I can't imagine using a password for any site that doesn't meet this requirement, and this is only one step that I'd encourage all users with administrator or higher access level to take to maintain security of their account. Risker (talk) 05:12, 14 December 2015 (UTC)[reply]
  27. --Krd 06:15, 14 December 2015 (UTC) Recently proven to be necessary. Should be required for all users.[reply]
  28. --β16 - (talk) 08:49, 14 December 2015 (UTC)[reply]
  29. --Grüße vom Sänger ♫(Reden) 10:47, 14 December 2015 (UTC) For me it's a nobrainer, that people with a certain level of access to trusted information should have secure passwords[reply]
  30. MER-C (talk) 11:04, 14 December 2015 (UTC)[reply]
  31. עוד מישהו Od Mishehu 13:38, 14 December 2015 (UTC)[reply]
  32. --RexxS (talk) 15:12, 14 December 2015 (UTC)[reply]
  33. Julle (talk) 15:51, 14 December 2015 (UTC) When I support someone's request for adminship or other rights, I trust their ability to handle those tools and behave according to Wikimedia social norms and expectations. I don't ask if they've got basic knowledge about computer security. We can't expect everyone will have. This doesn't mean they're not trustworthy, it simply means they've never been taught basic steps to keep their accounts safe.[reply]
  34. As a simple security measure to keep advanced permissions away from people with ill intent. Explicily oppose doing this for all users. Wikimedia projects should be easy to access and edit, this is only to prevent harm caused by compromised accounts with advanced permisssions. Beeblebrox (talk) 16:16, 14 December 2015 (UTC)[reply]
  35. Absolutely. wctaiwan (talk) 17:56, 14 December 2015 (UTC)[reply]
  36. APerson (talk) 18:29, 14 December 2015 (UTC)[reply]
  37. Absolutely for advanced user rights. These accounts can do a lot of damage if compromised. However, I strongly oppose imposing the requirements on all accounts. One of the big issues facing us is lack of new editors. We want to keep the bar low. Also, why on earth go to the trouble to steal a vanilla autoconfirmed account. Just create an account, fix 10 typos and wait 4 days. Happysquirrel (talk) 19:39, 14 December 2015 (UTC)[reply]
  38. After the account compromise over at EN.WP admins etc need to have better passwords, The only thing I oppose is making this a thing for all users as it wouldn't really benefit us non admins. –Davey2010Talk 00:56, 15 December 2015 (UTC)[reply]
  39. ⋙–Berean–Hunter—► ((⊕)) 02:07, 15 December 2015 (UTC)[reply]
  40. Teles «Talk to me ˱C L @ S˲» 03:35, 15 December 2015 (UTC) A simple measure with no harm for users. We shouldn't be so naive for believing that every sysop on every Wiki will care about their account security. Let's not be so passional about that and acknowledge that not everyone care about it but should and it isn't understandable to be so worried about requiring security measures from users with higher access. We are not dealing with readers and new editors; sysops can easily deal with any possible harm that comes from this. Those that already care won't be affected.[reply]
  41. -Grind24 (talk) 04:23, 15 December 2015 (UTC)[reply]
  42. WormTT 08:38, 15 December 2015 (UTC)[reply]
  43. --Atsme📞📧 18:49, 15 December 2015 (UTC)[reply]
  44. Kharkiv07 (T) 22:33, 15 December 2015 (UTC)[reply]
  45. Alan (talk) 00:00, 16 December 2015 (UTC)[reply]
  46. Johnuniq (talk) 03:53, 16 December 2015 (UTC)[reply]
  47. --L736E (talk) 23:03, 17 December 2015 (UTC)[reply]
  48. Ruy Pugliesi 03:51, 21 December 2015 (UTC) Accounts with advanced permisssions can cause a lot of damage if compromised. May it sound as a message of distrust? Yes, maybe. However, I believe it is essential to prioritise security measures.[reply]
  49. MisterSynergy (talk) 07:39, 21 December 2015 (UTC)[reply]
  50. --YMS (talk) 08:03, 21 December 2015 (UTC) Good measure to protect our wikis; also it's good that no "advanced" requirements like "has to have at least two special characters and one number" are to be forced.[reply]
  51. --PeeCee (talk) 08:05, 21 December 2015 (UTC) Being a PenTester i know how easy it would be to exploit weak passwords. --PeeCee (talk) 08:05, 21 December 2015 (UTC)[reply]
  52. --Windharp (talk) 08:23, 21 December 2015 (UTC) - That is not a question about trust/distrust but about reducing the risk of password hacking attempts.[reply]
  53. --Martinvl Although I trust 99% of the privileged users not to abuse their privileges, I do not trust 100% of them. I also do not know which 1% I should distrust. The weak link in Wikimedia's security system is a disgruntled employee which is why privileged users need secure passwords. Martinvl (talk) 08:27, 21 December 2015 (UTC)[reply]
  54. --Klaus Eifert (talk) 08:30, 21 December 2015 (UTC)[reply]
  55. --Sfic (talk) 08:35, 21 December 2015 (UTC)[reply]
  56. --sasha (krassotkin) 08:38, 21 December 2015 (UTC)[reply]
  57. --Edoderoo (talk) 08:41, 21 December 2015 (UTC) Sure, I would force 2-pass for certain positions once it is available. For regular users (non-sysops), a one-byte password could still do, for all with extra responsibilities, I support.[reply]
  58.  Klaas `Z4␟` V08:47, 21 December 2015 (UTC) absolutely! Not only admins for everybody to make the procedure more universal and therefore simpler.[reply]
  59. -- I recommend to use at least a 12-character password. --Misibacsi (talk) 08:50, 21 December 2015 (UTC)[reply]
  60. -- THE IT (talk) 09:01, 21 December 2015 (UTC)[reply]
  61. —Absolutely Beeswaxcandle (talk) 09:03, 21 December 2015 (UTC)[reply]
  62. should be for every user. Turb (talk) 09:05, 21 December 2015 (UTC)[reply]
  63. --- Darwin Ahoy! 09:09, 21 December 2015 (UTC)[reply]
  64. --Susann Schweden (talk) 10:03, 21 December 2015 (UTC)[reply]
  65. --Yann (talk) 10:26, 21 December 2015 (UTC)[reply]
  66. Everybody ought to understand that these requirements are not against anyone's rights but instead protect the system against abuse. That 8 bytes minimum should be for every user and at least 24 bytes for users with advanced permissions. --Chiumbi (talk) 11:25, 21 December 2015 (UTC)[reply]
  67. This is an absolutely basic level of password security. If your password is less than eight bytes, it can be trivially cracked (under a second). The opposing argument—that requiring reasonable password security for administrators (etc.) demonstrates a lack of trust—is quite frankly baffling to me. When we give out rights to administrators and CheckUsers and so on, the community is saying "we trust you to use your tools to make the wiki better". We aren't saying "we trust every decision you make". And the recent security issues with admin accounts clearly demonstrate that some people evidently need a little bit of assistance to not completely fail at infosec. —Tom Morris (talk) 11:35, 21 December 2015 (UTC)[reply]
  68. If find it strange that such a policy is not already in place for all users. --Sebari (talk) 11:42, 21 December 2015 (UTC)[reply]
  69. We need to make sure that the person in charge of privileged accounts is the same person elected by the community. Muhraz (talk) 11:50, 21 December 2015 (UTC)[reply]
  70. Banfield - Reclamos aquí 12:06, 21 December 2015 (UTC)[reply]
  71. --DR (talk) 12:18, 21 December 2015 (UTC)[reply]
  72. Euryalus (talk) 12:26, 21 December 2015 (UTC)[reply]
  73. Yes, of course. MaxBioHazard (talk) 12:32, 21 December 2015 (UTC)[reply]
  74. --Insider (talk) 12:42, 21 December 2015 (UTC)[reply]
  75. Yes. It seems reasonable. Regards. --Ganímedes (talk) 13:33, 21 December 2015 (UTC)[reply]
  76. Jmvkrecords (Intra talk) 13:45, 21 December 2015 (UTC).[reply]
  77. --Asger (talk) 13:50, 21 December 2015 (UTC)[reply]
  78. It surprises me that the requirement isn't higher -- many vendors require that to open an account, you use a password that is not only eight bytes, but that includes some or all of upper and lower case alpha, numbers, and special characters. Where permitted, I always use passwords that contain at least three of the four.     Jim . . . . Jameslwoodward (talk to me) 14:02, 21 December 2015 (UTC)[reply]
  79. Support Support; I see no reason not to support this. —Beleg Tâl (talk) 14:21, 21 December 2015 (UTC)[reply]
  80. I can't conceive of any logical reason to oppose this. Thryduulf (talk: meta · en.wp · wikidata) 14:22, 21 December 2015 (UTC)[reply]
  81. This proposal makes sense. — Green Zero обг 14:26, 21 December 2015 (UTC)[reply]
  82. Yes, but...security isn't in the number of bytes in the password, but the number of guesses allowed from unrecognized systems. -- Dave Braunschweig (talk) 15:27, 21 December 2015 (UTC)[reply]
  83. +Dave Braunschweig – Meiræ 16:03, 21 December 2015 (UTC)[reply]
  84. Additional protection agains brute force attack is nessesary, ie. only a limites number of guesses in a certain time space. But the requirements should only be used on accounts mentioned in the proposal. ----Savfisk (talk) 16:27, 21 December 2015 (UTC)[reply]
  85. NH 17:02, 21 December 2015 (UTC)[reply]
  86. Peter Bowman (talk) 18:06, 21 December 2015 (UTC)[reply]
  87. Matanya (talk) 18:39, 21 December 2015 (UTC)[reply]
  88. Kropotkine 113 (talk) 18:47, 21 December 2015 (UTC)[reply]
  89. FiliP ██ 19:15, 21 December 2015 (UTC)[reply]
  90. --Gestumblindi (talk) 19:30, 21 December 2015 (UTC) Though this wouldn't necessarily mean that people choose a good password, and it can't prevent careless handling of passwords or using the same password as for other services, it still seems like a reasonable basic standard that, in fact, would be a good idea for all users.[reply]
  91. --Koffeeinist (talk) 19:52, 21 December 2015 (UTC)[reply]
  92. --Alchemist-hp (talk) 20:01, 21 December 2015 (UTC)[reply]
  93. k6ka 🍁 (Talk · Contributions) 20:28, 21 December 2015 (UTC)[reply]
  94. Anyone who opposes this is a nitwit. Any admin/bureaucrat/etc. who opposes this should have their tools taken away for willfully endangering other users while in a position of trust. — Scott talk 20:38, 21 December 2015 (UTC)[reply]
    Wow, a non sequitur, ad hominem and an ad baculum. This should be some kind of record. Natuur12 (talk) 22:30, 21 December 2015 (UTC)[reply]
  95. Per my comments on the English Wikipedia RfC: basically, that we need to make sure accounts with the power to mess up the site have fairly secure passwords, while avoiding excessive rules for regular users. — Bilorv (talk) 20:43, 21 December 2015 (UTC)[reply]
  96. --Lam-ang (talk) 21:13, 21 December 2015 (UTC)[reply]
  97. It’s a start. U2F would be better. --DaB. (talk) 21:44, 21 December 2015 (UTC)[reply]
  98. Obvious support - This should be baseline for all users. Reaper Eternal (talk) 21:54, 21 December 2015 (UTC)[reply]
  99. Per Reaper Eternal just above, this is the minimal security requirement for a large majority of website nowadays — 0x010C ~talk~ 22:21, 21 December 2015 (UTC)[reply]
  100. Duh. --Thibaut120094 (talk) 22:35, 21 December 2015 (UTC)[reply]
  101. Eduardogobi (talk) 22:56, 21 December 2015 (UTC)[reply]
  102. MichaelMaggs (talk) 22:59, 21 December 2015 (UTC)[reply]
  103. Basvb (talk) 01:05, 22 December 2015 (UTC) These are the least that should be required from passwords.[reply]
  104. On WordPress.com your password should be at least six characters long and it's just a blogging service. Here we are talking about the security of all users on a wiki. Although 8 bytes may still be not secure enough and admins should be reminded of this, it seems a reasonable minimum requirement to me. Dalba 03:19, 22 December 2015 (UTC)[reply]
  105. Support Support xaosflux Talk 03:41, 22 December 2015 (UTC)[reply]
  106. Support Support. 8 bytes (or characters) password seems OK to me. --Warp3 (talk) 04:43, 22 December 2015 (UTC)[reply]
  107. Technically speaking, by eliminating the most common passwords, that leaves attackers with a smaller set of possible passwords to choose from, which sorts of makes it easier for them ("hmm... I know what not to try"), but then, the restrictions also make it harder to brute force the password. It would probably be good to apply this to other accounts such as bots (and potentially all users overall) as well.  Hazard SJ  04:45, 22 December 2015 (UTC)[reply]
    The passwords that are eliminated take up such a small amount of the password space, that its basically inconsequential (particularly, the common password list is very small. The 8 byte limit would eliminate a bigger portion of the password space, but still only an extremely small amount. Even under the very liberal assumption that passwords are at most 8 bytes long, only 0.3% are eliminated (Math I did was a bit simplified, so take that as a ballpark). If you assume passwords are at most 9 bytes long, then it eliminates 0.001% of the password space. I wouldn't worry about eliminating such a small amount of the potential password space. BWolff (WMF) (talk) 12:50, 22 December 2015 (UTC)[reply]
  108. In my opinion a stronger password should be implemented to all users. All the best, --Silenzio76 (talk) 14:11, 22 December 2015 (UTC)[reply]
  109. --SMAUG (TalkMy contributionsE-mail) 14:36, 22 December 2015 (UTC)[reply]
  110. Support Support I would also strongly encourage 2-factor authentication as soon as possible, and forcing a password change on everybody once in a while. I can't understand the motivation of somebody opposed to this; if you are not willing to be positively identified as the same unique individual over time, then why should we trust you with any special rights? ArthurPSmith (talk) 14:45, 22 December 2015 (UTC)[reply]
  111. Support Support Doug Weller (talk) 15:18, 22 December 2015 (UTC)[reply]
  112. Support Support --Atcovi (Talk - Contribs) 15:30, 22 December 2015 (UTC)[reply]
  113. Firilacroco talk 16:47, 22 December 2015 (UTC)[reply]
  114. Support Support Strongly support. I think that admins and users with advanced access (e.g. stevards, oversighters, bureaucrats etc.) should use strong passwords. I think that system can notify users with advanced access that they use weak password and after 14 days remove the access. I thing that bans aren't neccesary. --Urbanecm (talk) 17:06, 22 December 2015 (UTC)[reply]
  115. Support Support --Tarjeimo (talk) 17:22, 22 December 2015 (UTC)[reply]
  116. Only as a temporary solution. I implore the Foundation to have its Security team make two-factor authentication a top priority goal for the next quarter, and have this working product delivered within this timeframe, and then have it forced on all accounts holding permissions that give them access to information covered by the privacy policy. odder (talk) 18:53, 22 December 2015 (UTC)[reply]
  117. Support Support I am not a friend of strong password requirements, as they reduce comfort of users. But these proposed new requirements are straightforward and uncomplicated, i do not think that these requirements will reduce comfort of users. And I agree that weak passwords are security threat. --Jklamo (talk) 19:54, 22 December 2015 (UTC)[reply]
  118. Support Support Zabia (talk) 20:16, 22 December 2015 (UTC)[reply]
  119. Support. --Allan Aguilar (talk) 21:19, 22 December 2015 (UTC)[reply]
  120. Support Support - plus what Esquilo said. Balko (talk) 23:26, 22 December 2015 (UTC)[reply]
  121. Support Support david55 (talk) 06:29, 23 December 2015 (UTC)[reply]
  122. Support Support - Rsocol (talk) 08:09, 23 December 2015 (UTC)[reply]
  123. Although the proposition above is quite far from a strong password that is a good start. Soisyc Croisic (talk) 10:16, 23 December 2015 (UTC)[reply]
  124. Support Support - --Alexander Gamauf (talk) 11:42, 23 December 2015 (UTC)[reply]
  125. Support Support Mardetanha talk 20:20, 23 December 2015 (UTC)[reply]
  126. Support Support I have read through the "oppose" votes, and see nothing in that discussion to cause concern. Those proposing this have clearly thought through the alternatives and considerations thoroughly. Well done. -Pete F (talk) 17:52, 24 December 2015 (UTC)[reply]
  127. In fact, I do not see the point for this poll, just do it. --FocalPoint (talk) 18:28, 24 December 2015 (UTC)[reply]
  128. Support Support I am not sure if I am allowed to vote, but I totally think it's a good idea. What if Jimbo's password was just "WikipediaIsGr8"? That wouldn't be good.... Krett12 (talk) 21:31, 24 December 2015 (UTC)[reply]
  129. Support Support WMF seems to offer secure environment. Nevertheless, strong passwords are necessary at least for users with higher rights. Juetho (talk) 09:06, 25 December 2015 (UTC)[reply]
  130. Support Support.--Stang 13:28, 25 December 2015 (UTC)[reply]
  131. Definitely yes. Every actions created to increasing the safety for users accounts with advanced permissions receive my support. Damages caused by invasions of these accounts can be catastrophic. Érico (msg) 19:19, 25 December 2015 (UTC)[reply]
  132. Support Support per Jklamo. –Danmichaelo (talk) 17:23, 26 December 2015 (UTC)[reply]
  133. Support Support --° (Gradzeichen) 11:13, 27 December 2015 (UTC)[reply]
  134. Support Support --Nux (talk) 13:31, 27 December 2015 (UTC) I would even make those demands higher, but I guess it should be fine. Maybe you could also add some basic entropy meter in the form. Just as a hint for users.[reply]
  135. Support Support PMG (talk) 18:32, 27 December 2015 (UTC) full support for this RFC and for 2FA.[reply]
  136. Support Support Unicornisaurous (talk) 21:05, 27 December 2015 (UTC)[reply]
  137. Effeietsanders (talk) 23:02, 27 December 2015 (UTC) - seems improvement enough. Dont let perfection be the enemy of progress![reply]
  138. 贊成。--Jasonzhuocn (talk) 08:00, 28 December 2015 (UTC)[reply]
  139. Support Support 100.6.47.23 15:32, 29 December 2015 (UTC)[reply]
  140. Support Support Karmela (talk) 22:56, 29 December 2015 (UTC)[reply]
  141. Support Support per most of the other comments above. This, that and the other (talk) 13:52, 1 January 2016 (UTC)[reply]
  142. Support Support In today's computing age 8 almost isn't long enough, but definitely a step in the right direction. -- Enfcer (talk) 03:09, 3 January 2016 (UTC)[reply]
  143. Support Support rxy (talk) 16:10, 3 January 2016 (UTC)[reply]
  144. Support Support „WHAT YEAR IS IT?“ Kays (talk) 06:06, 6 January 2016 (UTC)[reply]
  145. Support Support These are such basic requirements that I can't imagine any problems. We can always do more in the future. Respectfully, none of the oppose votes are convincing. — Earwig talk 08:33, 7 January 2016 (UTC)[reply]
  146. Support Support Ciridae (talk) 11:15, 8 January 2016 (UTC)[reply]
  147. Support Support Avm99963 (talk) 16:30, 8 January 2016 (UTC) – It's one step towards having more security in all Mediawiki projects. However, apart from this proposal I would give a lot of priority to the implementation of 2FA.[reply]
  148. Support Support It's about time that some basic security is required for contributors with advanced permissions. I would advocate even more stringent requirements. Royalbroil 03:54, 9 January 2016 (UTC)[reply]
  149. Support Support I don't really see any functional argument against standardizing security requirements and effectivly increasing user security. All opposing voices boil essentially down to "I don't like this" or "I trust people"...
  150. Support Support only for two-factor authentication. I mean, how are you going to check if a password which already set is strong enough or not to implement "users who don't have a strong enough password will be asked to change it next time they log in. Additionally, users that are in the restricted groups will be prevented from changing their password to a password not meeting the requirements."? Bennylin
  151. Strong support Strong support --Mario-WL (talk) 01:49, 15 January 2016 (UTC)[reply]
  152. Support Support A no-brainer. Kevin Rutherford (talk) 23:52, 18 January 2016 (UTC)[reply]

Oppose

//meta.wikimedia.org/w/index.php?title=Requests_for_comment/Password_policy_for_users_with_certain_advanced_permissions/oppose&action=edit


  1. I will not support this message of distrust in advanced right holders. --Vogone (talk) 12:19, 13 December 2015 (UTC)[reply]
    fwiw, this isn't really about distruting admins so much as making sure that the person we trusted is the person who is in control of the account. BWolff (WMF) (talk) 18:14, 13 December 2015 (UTC)[reply]
    It's perfectly reasonable to set up password requirements for admins (or higher), regardless of how much you trust them, when they have access to security-sensitive rights. --Krenair (talkcontribs) 18:18, 13 December 2015 (UTC)[reply]
    Trust also means to trust people protecting their accounts sufficiently. --Vogone (talk) 19:12, 13 December 2015 (UTC)[reply]
    When decided whether to trust someone, do you really investigate their account security? Or do you really just trust nobody? Your position is unacceptable from a security point of view. Anyway, I'll echo what Brian said above - this is about making sure the person logging into a privileged account is indeed the person we trusted with the rights that account has granted. --Krenair (talkcontribs) 19:38, 13 December 2015 (UTC)[reply]
    I would rather tend to say "investigat[ing] […] account security" is close to impossible, regardless if this proposal is implemented or not. Even if such password requirements were enforced, we would still need to trust the affected users not to use alternative, but yet equally "simple" passwords, not to use the same password across multiple platforms (which was btw the reason for the enwiki issue), etc. pp. I doubt the effectiveness of the proposed measure, it merely adds extra-code to the software. I understand why one would recommend passwords as it's been done in this proposal, but I disagree enforcing this by software is a useful thing. --Vogone (talk) 22:35, 13 December 2015 (UTC)[reply]
    We can only do so much in the software. This is not an issue of trust but of "we literally can't fix those problems". Your argument then seems to be that "longer passwords are not more secure", which is patently false, regardless whether a user drops "aaaaaaaa" into his "Enter password" field or drops a "!@#SQWtXZwAW3" into it. If there is an argument you should be making, it's that "limiting attempts to access a user account" is probably the most effective way to counter server-side loss-of-account, a policy I'm unsure whether Wikimedia enables on its wikis (I haven't tried to break into an account of late...). As you suggest, we can't do anything about user-idiocy. --Izno (talk) 14:37, 14 December 2015 (UTC)[reply]
    In other words: we can't do everything possible to fix security, so let's not do anything. —Tom Morris (talk) 11:26, 21 December 2015 (UTC)[reply]
    The position that I might trust administrators with whom I have never interacted pretty quickly sets this comment into the "dumb comments" piles. In that case, it is not that I trust them but that I have no evidence with which to distrust them, or that I simply do not know of them, meaning I don't care whether I trust or distrust them. Trust is not binary. --Izno (talk) 14:37, 14 December 2015 (UTC)[reply]
  2. No thanks. — regards, Revi 13:04, 13 December 2015 (UTC)[reply]
    Any particular reason to oppose? --Krenair (talkcontribs) 18:20, 13 December 2015 (UTC)[reply]
    Because I don't want it. If you want it, per Vogone, MF-W, Ajr. Why don't you ask the same questions for supporters? — regards, Revi 13:44, 14 December 2015 (UTC)[reply]
  3. No Thanks, too --책읽는달팽 (talk) 13:06, 13 December 2015 (UTC)[reply]
    See above. --Krenair (talkcontribs) 18:20, 13 December 2015 (UTC)[reply]
  4. Apparently the case on enwiki was the first in years globally where such a thing happened. I do not see any reason from it to introduce these global requirements. Also, I do not understand why this RFC is set up in adversiarial style (where there are even fancy buttons for adding a comment, instead of the edit section link, yikes?!) instead of a discussion section where arguments can be exchanged. --MF-W 16:51, 13 December 2015 (UTC)[reply]
    I thought the sections might be easier if the audiance might not all speak the same language. People should feel free to comment on other people's comments and exchange ideas as they see fit. The fancy buttons instead of edit sections is so that we can have subpages for the comments (in the hopes that makes translating the proposal easier) without the edit links going to the page where the header is instead of the subpage. I modelled the formatting of this RFC on the freebassel one. I'm not usually imvolved with these sorts of things so I dont know if its the best choice but it seemed reasonable at the time. BWolff (WMF) (talk) 18:14, 13 December 2015 (UTC)[reply]
    What's so scary about the fancy buttons linking to edit section instead of a normal link? It's not like you can't still comment on other's messages. And there's still a generic comment section below. --Krenair (talkcontribs) 18:18, 13 December 2015 (UTC)[reply]
    The button design looks like it will automatically vote (eg. vote «Oppose»), instead of allowing you to comment the Oppose section. I also think a normal link would be beneficial. Platonides (talk) 23:04, 13 December 2015 (UTC)[reply]
    It has happened on wp:fr, one time. --Nouill (talk) 04:19, 9 January 2016 (UTC)[reply]
  5. Oppose. Six random characters is secure enough, whereas one eight-letter common word isn't. Trying to enforce a certain level of entropy doesn't work. I think it's reasonable to assume the admins have some common sense when choosing passwords, and some existing secure passwords will probably need to be changed as a result of this. Sacrificing enough usability for security leads to losing security. Asking people to create new passwords means that you'll have a mess of people having difficulty remembering their new passwords, and trying to store their passwords in places in a very insecure manner, and some making passwords that are easy to remember at the cost of security. Forcing admins to change passwords from their long-used "Q´a8Z/" to "password" (or some less-exaggeratedly simple password) is a terrible idea. --Yair rand (talk) 18:37, 13 December 2015 (UTC)[reply]
    That assumes that all admins are technical people, knowing what is a secure password. Platonides (talk) 23:09, 13 December 2015 (UTC)[reply]
    This rig, dating from 2010, can check Microsoft's NTLM hash of every six-character password in two seconds. I appreciate that PBKDF2 is a considerable improvement, but eight random characters will always take almost 10,000 times longer to crack than random six characters. Is the increased difficulty in remembering eight characters rather than six worth that much weaker security? --RexxS (talk) 15:10, 14 December 2015 (UTC)[reply]
    You misread his argument--he said "six-letter random" and "eight-letter word", referring to loss of security by en:dictionary attack. --Izno (talk) 16:40, 14 December 2015 (UTC)[reply]
    I'm pretty sure I didn't misread his statement "Six random characters is secure enough". That's patently a false premise. --RexxS (talk) 12:13, 21 December 2015 (UTC)[reply]
    The point I am making about your response is that you are making a false comparison. From what I can see, and why we are advised to use random passwords to begin with, is that a dictionary attack is more likely than a brute force, making an 8 character single word passphrase less secure than 6 random characters. The argument he's making isn't the best regardless, but your counterargument doesn't seem to accept the above fact either. --Izno (talk) 20:57, 21 December 2015 (UTC)[reply]
    Just for context, howsecureismypassword.net says that "Q´a8Z/" would take about an hour to crack. —Tom Morris (talk) 11:29, 21 December 2015 (UTC)[reply]
    That site assumes the attacker can make 4 billion guesses a second. How many guesses an attacker can make a second depends on the attack model, and can be much higher than most people think... but 4 billion sounds a bit unrealistic to me in Wikimedia's setup (If we were using a plain hash instead of PBKDF, 4 billion might be realistic for an offline attacker). As for Yair rand's example 7 byte password ('´' is a non-ascii character and takes 2 bytes. Its also not on english keyboards, which might make it less likely to be hit by a dictionary attack). It would be secure against a brute force attacker who can do 1000/guesses a second (but pretty much just barely, probably). It might not be secure against a more powerful attacker. The security margin is less than what I would like to see on an admin account, but if I'm being honest, he's definitely correct that it would be much more secure than someone who chooses a poor 8 byte password. That said, an 8 byte password chosen in a similar good fashion would have a much higher security margin, and be very unlikely to be cracked. BWolff (WMF) (talk) 11:24, 22 December 2015 (UTC)[reply]
  6. Per Vogone, I trust advanced permissions holders to have secure passwords. If you're very concerned about security, have a two-factor authentication option available for use. Ajraddatz (talk) 22:40, 13 December 2015 (UTC)[reply]
    The people who would use a second factor if it was available are not the ones whose security we should be most concerned about. --Tgr (talk) 23:10, 13 December 2015 (UTC)[reply]
    If they are already using secure password, enforcing the above requisites should be no issue. Are you using a different definition? Platonides (talk) 23:51, 13 December 2015 (UTC)[reply]
    Nope, but if you trust advanced permissions holders to keep their accounts secure, then you can focus effort on other technical issues :-) Ajraddatz (talk) 23:59, 13 December 2015 (UTC)[reply]
    attackers go after the weakest link, not the links we want them to go after. Sure if we pretend the problem doesnt exist we could focus on other things (however, i would note that the technical work is already done, so its not like voting no saves effort). But that wouldnt do us any good as the things we are ignoring are the weak points. BWolff (WMF) (talk) 00:18, 14 December 2015 (UTC)[reply]
  7. Per Vogone, MF-W and Ajraddatz. -Mh7kJ (talk) 23:07, 13 December 2015 (UTC)[reply]
  8. Per Vogone. Matiia (talk) 23:34, 13 December 2015 (UTC)[reply]
  9. Per above. Jianhui67 talkcontribs 09:14, 15 December 2015 (UTC)[reply]
  10. Doesn't make any sense, IMHO. Though in general I'm fine with the proposal, it is clear that the holders of the rights mentioned must keep their accs safe, that's not a solution. It's like wasting money on security door (in this case we are speaking about not money but complicating code, probably making some operations run slower even if just a fraction of operations and just a fraction of speed) while the walls are made of plasterboard (and by this I mean email password on which we have no influence). I must a little bit disagree with Vogone though, while I trust most admins, in some projects, especially but not exceptionally in small ones, admin-flags are given not to (just) technically competent users but also/just as an award for good considerable contributions. Some people could just be ignorant of both the power admin flag provides and the means of account security necessary. --Base (talk) 22:28, 18 December 2015 (UTC)[reply]
  11. Forcing Wikimedians to lengthen the passkey: not a good idea. If I want to have only 6 characters, let me have 6!
    acagastya  ✉ Dicere Aliquid :) 07:58, 21 December 2015 (UTC)[reply]
  12. No, thanks. I'm really pissed of password-strength policy at my ex-ex-workplace. Because of stupid "have very secure password and change it every N days" people started to write down their passwords on sheets of paper. As experienced user I do understand what password is secure and what is not. Either you believe that i'm experienced enough to edit common.js AND select my own password by myself, or do not grant me any additional rights. -- Vlsergey-at-work (talk) 08:53, 21 December 2015 (UTC)[reply]
  13. Bad idea. A strong password in itself is not a panacea, and the problem here is not the strength of their passwords, but the fact it's a single point of falure. Passwords can be stolen in various ways, people can be socially engineered, etc. Introduce some code review process for these sensitive files so that at least two or better three admins see the changes before they go live. Also, one-time password support for logging in on untrusted machines would be much more useful. --Yury Bulka (talk) 10:32, 21 December 2015 (UTC)[reply]
  14. Strongly oppose. I have seen enough domains where password has to be changed on the regular basis. This results in storing the passwords in insecure way. Here we discuss single password change but for a lot of users in short time, thus kind of a heaven for hackers. Sir Shurf (talk) 10:53, 21 December 2015 (UTC)[reply]
    Just to be clear, we are not proposing that passwords would have to be changed on a regular basis. I would strongly oppose that type of measure since mandatory regular password changes are a royal pain, and there's about a million research articles on how requiring regular password changes reduces overall security. I just want people to be using a secure password that's not easily guessable. Hopefully most people already are, and they wouldn't even notice the change. BWolff (WMF) (talk) 11:09, 21 December 2015 (UTC)[reply]
  15. Everyone should have the freedom to choose an unsecure password. That's not our department.--Kopiersperre (talk) 11:50, 21 December 2015 (UTC)[reply]
  16. We have a word for this in my native language. Schijnveiligheid. Natuur12 (talk) 11:52, 21 December 2015 (UTC)[reply]
  17. Per above. --WindEwriX (talk) 12:20, 21 December 2015 (UTC)[reply]
  18. I agree with Natuur12, this is creating a safe feeling, but not real safety. I've had a password of four digits (two numbers and two lettres, one of them was a capital) that was perfectly safe. Dqfn13 (talk) 12:22, 21 December 2015 (UTC)[reply]
    As Arthur Dent said, "That's an interesting new use of the word 'safe' that I hadn't come across before." --RexxS (talk) 12:40, 21 December 2015 (UTC)[reply]
    2 numbers and 2 (I'm assuming english letters) = 10*10*26*26*2*2 = 270400 possible combinations ≈ 18 bits of entropy. So an attacker would need to make 217 guesses. If we assume 1000 guesses a second [How many guesses an attacker can make a second depends a lot on your attack model.], your password would be cracked in 4.5 minutes. BWolff (WMF) (talk) 11:12, 22 December 2015 (UTC)[reply]
    Is it possible though to brute force passwords like that for Wikimedia's accounts? Aren't there any limits on how many failed logins, say, per 30 minutes, are allowed for an account? --Yury Bulka (talk) 11:28, 22 December 2015 (UTC)[reply]
    There's two scenario's: - #1: In an offline attack, the attacker manages to somehow compromise the Wikimedia password list, and is only limited by the speed of their computer (We use PBKDF, so the speed of their computer is actually quite slow. My desktop can do about 2 pbkdf hashes per second, but an attacker might have specialized equipment [e.g. GPU based hashers], and should be assumed to be able to crack passwords several orders of magnitude faster.). Obviously, an attacker compromising the password file would be really bad, and will hopefully never happen. But it has happened to other high profile websites (e.g. LinkedIn, Adobe, lastpass), If we prepare for the worst, then we'll still be ok if it ever comes to pass (In particular, compare what happened to LinkedIn or adobe vs lastpass. Lastpass had much better systems in place, and survived the breach much better than adobe or LinkedIn). Scenario #2 is an online attack. This is where the attacker tries to guess passwords by directly logging in. Currently we have two limitations: If there have been 5 failed attempts in less than 5 minutes to login for a specific user from the same IP, then further attempts are prevented until the 5 minutes are up. Additionally, if there are three failed login attempts for any user, all from the same IP, then a CAPTCHA is shown for anyone trying to log in from that IP for the next 5 minutes (Keep in mind, our captchas aren't exactly high quality). However, an attacker might control thousands of IP addresses (e.g. Command a Botnet). Additionally, the online attack is also limited by how fast WMF servers can hash PBKDF (One would hope that would not be the limiting factor in the online scenario) I feel that there's probably a lot we could do to better limit attackers in the online scenario that we aren't doing currently (phab:T122164). Last of all, we do have logging of failed login attempts in place (especially for admins). If someone is making a large number of attempts to log in to an admin account, it would eventually get noticed in the server logs, so they wouldn't be able to keep up doing it for very long. In conclusion, to answer your question - Maybe. Depends on a lot of factors. In the ideal case no they wouldn't, at the very least they would get noticed. But we should plan for things to go wrong. BWolff (WMF) (talk) 13:21, 22 December 2015 (UTC)[reply]
    Thanks for the detailed answer. This is good to know, and it also confirms that in a realistic scenario it is more likely that if one wants to really exploit this, they'd rather try to compromise the computer used by an admin and steal their password (how often do admins leave their machines unattended on mass gatherings like Wikimania or local wiki conferences?), or even force the admin to surrender the password, which, unfortunately, is also a risk to consider if we're talking about an admin who lives in some tough country. This is why it can only be solved with some transparent code review process for the sensitive pages. --Yury Bulka (talk) 14:47, 22 December 2015 (UTC)[reply]
    Yes, if someone is able to get a keylogger on an admins machine, or in an extreme case, use "rubber-hose" cryptanalysis (euphemism for beating a password out of someone), then its pretty much all over regardless of how secure the password is. However, most attackers over the internet won't have the type of access to beat a password out of someone (One hopes), and that type of attack contains a much higher risk level for the attacker. So in practice, there's still a large class of attacker who would use password guessing (much larger than the the class who would use a more direct approach), as doing a simple repetitive guessing attack is unlikely to have real world consequences, and can be done without physical access to the victim. BWolff (WMF) (talk) 20:46, 22 December 2015 (UTC)[reply]
  19. This measures do not provide security, they just give false sense of security. Eight bytes in UTF-8 encoding is four cyrillic characters. The password "ключ" is not secure in any way. Neither is «𦈘𦈘» (4 bytes per character). And last time I checked, the word "пароль" (password in Russian) was not on RockYou list at all. --Grebenkov (talk) 17:59, 21 December 2015 (UTC)[reply]
    Its meant as a minimum standard. Ultimately we can't stop people from doing stupid things. This will hopefully prevent people from doing extremely stupid things and help educate people who don't know better. For non-english passwords - there may be more bytes per letter, but there are also more letters when you include all languages not just english, and those letters are also rarer. So there's an argument to be made that 1 non-latin letter is worth 2 latin letters. But that also depends on if the attacker knows that your password is all Cyrillic. I didn't find very many common password lists that had non-english passwords on them (If you know any, please let me know). Although it might be a good start to add everything listed at d:Q161157#sitelinks-wikipedia. From what I've heard, there's also quite a bit of bias among people who crack passwords, to generally try english passwords instead of other languages, but I don't know how true that is, and I don't have a source. BWolff (WMF) (talk) 11:12, 22 December 2015 (UTC)[reply]
  20. solves a problem not in evidence. need to improve admin passwords. the prescriptive rulemaking is not a solution, rather need to train those with responsibility to practice good security. need to implement better security than passwords, such as encryption. Slowking4 (talk) 19:58, 21 December 2015 (UTC)[reply]
    Can you go into more detail by what you mean by "need to implement better security than passwords, such as encryption". BWolff (WMF) (talk) 11:12, 22 December 2015 (UTC)[reply]
    i'm suggesting that we do not know what the state of password practice is; we need training in good practice. see the comments of Guy Macon [3] or Schneier [4] i'm suggesting encryption is a better solution, PGP is possible, for trusted accounts. it is the future, might as well get started. Slowking4 (talk) 16:14, 22 December 2015 (UTC)[reply]
  21. Oppose per Yair rand. It’s a nice try to enforce responsibility on the parties involved, but as noted above by the proposer himself, we can’t stop people from doing stupid things.

    We can, of course, pretend that we’ve stopped some of them doing some of these things, but it has more to do with our perception than with security itself.

    Ivan Shmakov (dc) 16:40, 22 December 2015 (UTC)[reply]

  22. Per Vogone, if we trust users to use these rights sensibly, then we can trust them to have a secure password. Using bytes to determine the security of a password simply makes no sense. Password security is more complex than simply string length. Caliburn (talk) 17:39, 22 December 2015 (UTC)[reply]
  23. First, passwords are not reliable anymore. Any script kid now has tens or hundreds of millions of passwords they can check in no time. Imposing a longer password will only give a false sense of security. If we are truly worried about security, we should consider 2-factor authentication or similar.
    Secondly, while one can do a lot from MediaWiki:Common.js, this is generally a well-followed page and changes to it do not go unnoticed. Therefore I don't see the need to impose additional requirements to users who can edit that file.--Strainu (talk) 18:10, 22 December 2015 (UTC)[reply]
    We use PBKDF to make password checking take time. But ultimately that's why complex passwords are important. A good password will take a lot more than a million tries to guess. As for JS. Depending on the attack, the attacker might only need to control that page for a very short time. The attacker can also insert code to make sure his/her changes don't show up on the usual lists. Also, MediaWiki:Common.js is the most well known js page, its hardly the only one. There are other pages in MW namespace that allow javascript injection, many of which are rather obscure. BWolff (WMF) (talk) 20:52, 22 December 2015 (UTC)[reply]
    Are we talking about PBKDF as in RFC 2898 ? I'm not very familiar with it, how much time does it actually take to check 100M passwords with that, compared to a simple hash? But my point was the limitations you're planning to introduce are useless if the users already used the same (complicated) password in other websites that were compromised and their password is now freely available on the internet, along with their associated username and/or email address.--Strainu (talk) 15:09, 24 December 2015 (UTC)[reply]
  24. I don't see any permissions of admins that would justify elevated security measures; anything admins can do, can easily be reverted by any other admin. So I doubt the necessity of such a change of policy. OTOH so far I used a pretty weak password here, as I initially gave WP a pretty low security level. So I just changed it to a somewhat higher, but still modest level. --h-stt !? 09:49, 23 December 2015 (UTC)[reply]
  25. Oppose - It'll take until well beyond the heat death of the universe to crack my password by brute-forcing it while offline. If we consider that as insecure, how is the two-factor authentication any better? This is only a pretense of security, because, if the password can somehow be compromised despite this, it will require someone either (1) breaking into my machine and RAT-ing it, or (2) breaking into the WMF's servers and accessing the database directly. Both get around the need for a password or 2FA in the first place. Reaper Eternal (talk) 15:36, 23 December 2015 (UTC)[reply]
    Why have you voted in both support and oppose sections? --Glaisher (talk) 15:43, 23 December 2015 (UTC)[reply]
    Umm, there is no password that both fails to meet the proposed requirements, and would take longer than the heat death of the universe to crack in an offline attack. So I'm not sure why this is an argument to oppose the minimum password strength requirements. If your password is really that secure, it is above and beyond the requirements being proposed here. BWolff (WMF) (talk) 00:14, 24 December 2015 (UTC)[reply]
  26. Oppose There's no need for such a security feature. --Morten Haan (talk) 00:53, 29 December 2015 (UTC)[reply]
  27. Oppose as Caliburn. --Ricordisamoa 02:38, 31 December 2015 (UTC)[reply]
  28. Oppose As Vogone. --Holder (talk) 16:56, 11 January 2016 (UTC)[reply]

Comentarios

//meta.wikimedia.org/w/index.php?title=Requests_for_comment/Password_policy_for_users_with_certain_advanced_permissions/comments&action=edit
  1. I can really recommend using CrackLib to valid card generator. Simple rules like "at least eight chars long with both digits and capitals" are too rigid to be useful. A 32 char lowercase only password is stronger than a seven char word with a digit appended to the end. CrackLib is superior when it comes to verifying password strenght. /Esquilo (talk) 08:57, 21 December 2015 (UTC)[reply]
    1. I think I can support the use of cracklib, at least on the sensitive accounts. — Finn Årup Nielsen (fnielsen) (talk) 09:53, 21 December 2015 (UTC)[reply]
  2. I would like to suggest that in addition to the above, the passwords should include at least one upper case letter, one lower case letter and at least one number. Preferably 2 of each. I would also add this suggestion isn't a lack of trust on the individual with the account on the WMF sites, its the reality that some outside the sites do not care about site policy. Reguyla (talk) 20:30, 13 December 2015 (UTC)[reply]
    Is this irony? --MF-W 21:51, 13 December 2015 (UTC)[reply]
    Not sure what you mean? But I assume its directed at my comments about certain admins and editors not following policy and nothing being done about it. Which is out of scope of this RFC! Reguyla (talk) 22:17, 13 December 2015 (UTC)[reply]
    I wasn't sure whether your suggestion of such a precise prescription (2 occurences each of some kinds of characters) was serious or not. Partially I thought so because only recently I read a "meme" somewhere on the internet about "Swabians choosing a safe password" (in German), where the victim of the joke tries to set a new password, but his choices are always rejected because something (e.g. a number, an uppercase letter) is missing. --MF-W 00:17, 14 December 2015 (UTC)[reply]
    Oh ok thanks for the clarification. Those are common practices in the industry is all. In fact most recommend using special characters as well such as %, ^ and & but I think that would be overkill for this site. Reguyla (talk) 14:40, 14 December 2015 (UTC)[reply]
    This sounds like dictating the style of password, which might be more than one wants to do. I don't recall what upper limit there is on password length, but I recall some advice from some time back that passwords ought to be long natural-language phrases, which is an entirely different style of password that could be extremely hard to crack but might be all lower-case with no numbers. Just a passing thought.

    Re trusting individuals, trust is always a relative thing. If you have 100 people and you're 99% sure of each of them, iirc there's something like a 75–80% chance that you're wrong about one of them. Likewise for 1000 people you're 99.9% sure of. --Pi zero (talk) 23:30, 13 December 2015 (UTC)[reply]

    I dont think we should make complexity requirements, or if we did, i think we'd want something much more complicated than that (as xkcd says: correct horse battery staple is a good password). Length matters much more than complexity. Re pi zero: upper limit on password length is 4096 bytes. Which should be enough for anyone, unless you use an epic pass-poem. BWolff (WMF) (talk) 23:59, 13 December 2015 (UTC)[reply]
    It's a good point. A long enough password doesn't need so much variety of characters. Platonides (talk) 00:08, 14 December 2015 (UTC)[reply]
    The random password generation algorithm I usually use has a tendency to produce passwords lacking punctuation and digits. When the site I’m registering at states that the password must have a digit, I invariably append ‘1’ to the string. When the site requires punctuation as well, I put ‘!’ (that is: Shift+1) at the end. Now, may I doubt that these measures actually improve my password strength? (That said, only a few sites I’ve needed to register at use such a formal approach to security, but still.) — Ivan Shmakov (dc) 17:45, 22 December 2015 (UTC)[reply]
  3. I can't support the “for users with certain advanced permissions”: this should apply to all users without exception. Let me adapt what Brion said here for HTTPS: “If we can require [it] for some […], it would be irresponsible not to require [it] for *all* […].” Also, I have a very high esteem of most advanced right holders I know, but that doesn't prevent me from not trusting them when it comes to password security. No offense to be taken, really: security only works when you trust nobody. And for what it's worth, on frwiki, we've already had a sysop whose password was so simple another user was able to find it to impersonate him (it was in 2010). — Arkanosis 00:03, 14 December 2015 (UTC)[reply]
    Users with advanced permissions are a subset of all users :) Platonides (talk) 00:08, 14 December 2015 (UTC)[reply]
    Users with advanced permissions, if compromised, can harm Wikipedia in ways that an ordinary user cannot. If an account with no advanced permissions is compromised, it can cause little additional harm beyond what a sock would, other than to the reputation of the legitimate account holder. As the primary harm is to the person who selected the weak password, the case for forcing a stronger one, for their own good is weaker than for say an Admin. Monty845 (talk) 04:21, 16 December 2015 (UTC)[reply]
    If an ordinary user's account is compromised, the only harm that can be done is to the user's reputation. If an admin's account is compromised, there are ways they can shut down a wiki entirely for a few minutes (possibly longer, on some of the smaller wikis). --Carnildo (talk) 02:06, 17 December 2015 (UTC)[reply]
    Someone who knows what they are doing, can do things a lot worse with an admin account than shut down the wiki for a couple minutes. BWolff (WMF) (talk) 11:47, 22 December 2015 (UTC)[reply]
    Thanks for bringing this up; a long standing question of mine is: apart from increasing resource usage, what goal the HTTPS switch has thus achieved? What purpose will it serve once (and if) the measures documented in http://ietf.org/mail-archive/web/perpass/current/msg01979.html will become reality for a certain country some two weeks from now? Thanks. — Ivan Shmakov (dc) 17:45, 22 December 2015 (UTC)[reply]
    The news from Kazakhstan is indeed very concerning. Much of the threat assumptions around HTTPS, assume that the user has some method of eventually getting around the adversary (ie, the adversary does not control all network links into/out of the country), or the user considers simply not communicating in the case of an active attack. Kazakhstan breaks these assumptions. However, most governments are politically unwilling to go to the extremes that Kzakastan has gone to, at least so far (And hopefully it will stay that way) Anyways, HTTPS achieves the following goal:
    1. Making site faster (Most browsers require HTTPS for HTTP/2 SPDY [Edit: While the statement is true for HTTP/2 as implemented in practice, we are still using SPDY afaik]. SPDY better utilizes the network, and results in improved load times. This was never a primary goal for us with HTTPS, but its an important benefit to keep in mind. Often people frame HTTPS discussions as a cost vs benefit of security. Its important to remember that even if there was no security benefits, HTTPS would still be a net win as it makes things faster).
    2. Protection against eavesdropping from a purely passive attack (There's reasons to believe that several governments engage in mass deep packet inspection to see what people are doing on the internet (Not to mention the person sitting beside you on the same wifi), but aren't willing/able to resort to active attacks in the general case. HTTPS significantly improves user privacy in these cases [yeah yeah, side channels exist with packet length/timing, but that's significantly harder to pull off then just dpi])
    3. Protection from a shared-medium session stealing attack (AKA firesheep), or sniffing passwords against a purely passive adversary, or an active adversary that isn't capable of getting a rouge certificate. If we ignore the big evil governments spying on everyone for a second, and instead concentrate on the shady character using the same public wifi as you, this is the most realistic attack against someone using our site. HTTPS prevents it.
    4. Being able to detect, in principle at least, that an active attack is taking place - Even in the case of a rouge certificate, it would be at least possible for someone to detect what's going on (e.g. By comparing certificate hashes ala EFF's SSL observatory). Knowledge of an attack is the first step to dealing with an attack.
    5. Providing integrity to Wikimedia content against attackers who aren't willing to do what Kazakhstan is doing. A key part of Wikipedia is its neutrality. If an attacker could modify the contents of Wikipedia articles in transit, this could seriously undermine Wikipedia's credibility as a neutral source of information. I personally think this is an extremely important goal, which often gets forgotten in discussions around https.
    6. Making censorship of Wikimedia an all or nothing game (For people not willing to do what Kazakhstan is doing). With HTTPS, you can't censor by keyword. The most precise you can do is DNS poisioning to censor only a specific language of a specific project. Thus instead of allowing someone to censor a few key articles they care about, this forces censors to chose between censoring everything, or nothing. Whether or not this is a positive depends on who you ask. Some people think that this will tip the balance in favour of less censorship of Wikipedia as it requires much more political capital to censor all of Wikipedia instead of just a few key articles (See for example github in China.). Or it might result in larger amount of collateral damage, forcing censors to censor everything. I certainly know people who think this is a bad thing, and others who think its a good thing. [To be clear I'm talking about goals that various people have which I've heard of. I wasn't involved with the foundations efforts for the HTTPS rollout, and I'm not sure precisely what their security goals are. Based on public statements other people have made, I think the main goals with the foundation are probably user privacy against passive attackers [including nation-states], security of passwords/session tokens against low skill adversary on the same network, and performance gains from HTTP/2]BWolff (WMF) (talk) 23:03, 22 December 2015 (UTC)[reply]
    To clarify: my objection was primarily on the for all users part; that is: the inclusion of the casual (as in: no account) readers. It wasn’t my intent to question the value of HTTPS for either the readers versed in communication security or non-IP contributors. Protection against session and password stealing, as well as the ability to detect tampering, are indeed valid uses for HTTPS.
    1. Making site faster (Most browsers require HTTPS for SPDY […]) – first, I see no reason for WMF to promote the reliance on such a software deficiency. Then, are there any numbers to support that HTTP/2 or SPDY over HTTPS outperform plain-HTTP (possibly with compression) when a LAN-accessible caching proxy is involved – in, say, class-room use cases (multiple clients obtaining the same HTML and images), and assuming the uplink bandwidth in the order of 512 kbit/s? (Which I believe may still be widespread in Kazakhstan; as well its neighbors, including the rural areas in Russia, etc.) The near-impossibility to use site-wide caching is still a drawback of HTTPS – as is its higher CPU cost. (Both client- and server-side. Granted, I know of no example of a country with a significant portion of Internet users relying on i586 or older hardware, but I don’t know for sure that no such country exists, either.)
    2. As an aside, in The Road Ahead, it’s suggested that the software should “advertise itself” – that is, that an average user should be able to discern the new version from the old from the first glance. I believe that the switch to the Australis theme in Firefox back in 2013 (to much of the chagrin of those of us who use the browser since its Netscape Navigator days) lies perfectly in line with this approach. And although I may be wrong, my guess is that the refusal to support SPDY or HTTP/2 on plain-HTTP connections may be an attempt to earn an easy “PR-point” for the software involved. (“Because we care about your privacy” sounds like a good slogan, indeed, even if all of their care is doomed to fail due to the user’s own carelessness.)
    3. The Foundation’s own decision regarding HTTPS doesn’t look dissimilar, actually – trying to enforce privacy (or how do we call that?) doesn’t do any good to the average Joe; in the best case, there is little to no difference (apart from possible performance boost, which should be achievable irrespective of TLS, as peree above); in the worst – the Wikimedia project that’s found to host content outlawed in the country becomes inaccessible in its entirety. And the credibility may be impaired regardless, thanks to whatever mass media the state (or other interested party) in question happens to own.
    4. Another question is whether we consider Internet “the library of the future”? The last time I was at a conventional library, it had large reading rooms, and the readers were passing by the tables occupied by other readers – with pretty good chance of violating their privacy by spotting the particular material being read. When HTTPS became mandatory for the Foundation resources, we have in effect forbade the reading of Wikipedia in libraries that do not provide “private space” for their entire readerships. Now, doesn’t it sound a bit… unusual (for lack of a better word) when stated this way?
    5. Finally, I’d appreciate Wikimedia projects becoming accessible as Tor “hidden services”, for such a setup can offer much better privacy than any TLS service that does not utilize onion routing of some kind.
    6. Making censorship of Wikimedia an all or nothing game – indeed, it’s debatable whether that’s an improvement or the exact opposite. As the recent events have shown, the Russian authorities and judges do not mind censoring specific articles on Russian Wikipedia even if that, as the law requires, means censoring Wikipedia as a whole. And it makes me wonder for how long could a Wikimedia project persists should the majority of its readers be filtered off by the applicable law? (And won’t that lead to a rise of some rival, perhaps state-sponsored, and thus quite likely non-neutral, projects, like Baidu Baike that for long time flourishes in PRC?) Thus, I guess I’m in the camp who believe that the “nothing” here by far outweighs the “all”. (Then again, with Wikipedia content being free, state-sponsored mirrors are quite a possibility. As well as, why, mere HTTP-to-HTTPS proxies.)
    Ivan Shmakov (dc) 19:17, 23 December 2015 (UTC)[reply]
    1. I'm not sure how common caching proxies are in the modern internet. However in our case we want edits to show up immediately, so we send headers disabling proxies not under our control (WMF has proxy server clusters in Amsterdam and San Francisco). Any conforming HTTP proxy will not cache wikimedia pages (they might possibly have cached images though. Its unclear what impact https would have in that regard. Although I'll note that user are generally much more tolerant of latency loading image then they are of latency loading text). In regards to compression - we always use HTTP compression (gzip) if the client supports it. For the average user, there was definitely a signficant improvement in load time with HTTPS for everyone. See load time graphs from June 2015 [You may need to scroll a little bit. If I'm interpreting the graph right, there was a 20% improvement. Which is extremely significant] (HTTPS for everyone was deployed the week of June 11-16 2015). I'm doubtful that the CPU performance cost of TLS is noticable. On the client side the user only has to do a very small number of expensive encryption operations, so I doubt its noticeable. On the server side which is likely the side that is likely to be more affected by CPU cost of encryption, google reports that encryption for everybody only used 1% of their CPU [5], so its really not the case that HTTPS has a high CPU cost.
    2. You're right that the SPDY only on HTTPS could be seen as a cheap political trick to force SSL adoption (I don't think its an attempt to get PR points. Users are totally unaware of if SPDY or HTTP/2 is in use, and most users have a poor understanding of the privacy implications of internet communication. I think its a trick to try to force SSL adoption on a wide scale, in order to make passive surveliance on a wide scale impractical. This is a political goal that many (not all) people in the internet community have. Basically to implement the agenda suggested by RFC 7258). That said, ultimately we are not the one's in control of that. Well many people in Wikimedia support such a goal, even if everyone in Wikimedia didn't like that goal, we'd still have to play ball.
    3. Wikipedia as a library is an interesting comparison, that comes up a lot. I'm not sure your analogy is apt. Sure people can look at what your reading in a library. But I think this is closer to people looking over your shoulders when you browse wikipedia in public. Traditionally libraries are very protective of their lending records, and don't release them. A massive passive attack from an internet backbone seems closer to a library (or all libraries) giving away their lending records, then it does to someone in the same room seeing what book you're reading.
    4. I think the more important bit for TOR is to come up with some sort of compromise to allow editing from TOR nodes (Without needing a GIPE flag). I've never really understood why people want hidden service nodes for services with public locations. As far as I know, that doesn't increase the anonoyminity, and adds 3 extra hops and a lot of extra latency (OTOH, it means that one doesn't need to use an exit node, which are in short supply. Maybe avoiding exit node bandwidth limitation outweighs the extra hops needed for hidden service. I have no idea) BWolff (WMF) (talk) 00:01, 24 December 2015 (UTC)[reply]
    1. I’m not sure how common caching proxies are in the modern internet. – my current employer uses a proxy for virtually all the employees’ (numbering no less than 750, I guess, although the official Web site remains secretive on this) Internet traffic for the purposes of authentication. (The logs are kept for several months, as required by the law, and were disclosed to the authorities upon request on several occasions.) I believe that the proxy in use does cache.
    2. Any conforming HTTP proxy will not cache Wikimedia pages – as long as we talk about free software, the decision of whether or not to conform, and to what extent, lies ultimately in the hands of the user (that is: proxy administrator.) I certainly would try to configure my proxies to cache for a couple of minutes or more, when the use case warrants for that. Then, however, HTTP provides enough facilities to check whether the resource has changed or not, which could be used to cache for extended periods of time, yet still have the edits show up immediately. If MediaWiki cannot properly utilize these facilities as of yet, it’s an issue by itself.
    3. If I’m interpreting the graph right, there was a 20% improvement. – ACK, thanks for the pointer, I’ll check it out somewhat later. I guess I should note, however, that none of the browsers I typically use for Web-reading (apart from the Commons and similar resources, I mostly stick to a customized version of EWW and Lynx) appear to support HTTP/2 or SPDY. Curiously, cURL does support both “h2” and “h2c”, so obviously there’re those of us who are still concerned about plain HTTP.
    4. But I think this is closer to people looking over your shoulders when you browse Wikipedia in public. – I don’t see it being much different to the case when one read a plain-HTTP resource over a public Wi-Fi. A massive passive attack from an Internet backbone – I know of no evidence to support that apart from a few, the nations actually engage in such activities. Moreover, I did not suggest that we drop support for HTTPS; rather, my proposal is to bring plain HTTP support back, so that the users can decide for themselves; and those who would opt in are still ought to be more or less safe from such an attack.
    5. That said, ultimately we are not the one’s in control of that. […] even if everyone in Wikimedia didn’t like that goal, we’d still have to play ball. – well, we aren’t in control of the state laws across the world, either. I don’t think that means that we should mindlessly cooperate with the authorities when some state court decides that some specific information is harmful to minors and should not be distributed over the Internet (as was in the case of the Russian Wikipedia block this year); or does it?
    6. OTOH, it means that one doesn’t need to use an exit node, which are in short supply. – and even more so in the case the resource happens to be filtered for one or more of these nodes. As for being able to edit via Tor – sure, count me in.
    Ivan Shmakov (dc) 12:32, 26 December 2015 (UTC)[reply]
    Not allowing plain http is primarily about concerns regarding downgrade attacks AFAIK (e.g. sslstrip). Its important that the people who do want HTTPS will get it even in the face of an active attacker. Lynx is unlikely to get much benefit from SPDY/HTTP/2 as its optimized for webpages that load a lot of subresources (JS, CSS, images, etc). Lynx is less likely to benefit from this as it doesn't support images, css, js, etc. BWolff (WMF) (talk) 07:05, 28 December 2015 (UTC)[reply]
    1. Per sslstrip’s page linked above, it seems to be designed to intercept traffic on TCP port 80, which should be plain-HTTP already. Or do you mean that someone may want HTTPS but type an http: URI by accident or due to habit, and be prevented from being “upgraded” to HTTPS via a redirect? (Thanks for the link, BTW; seems like something I was loosely looking for recently.)
    2. Lynx is less likely to benefit from this as it doesn't support images, css, js, etc. – while the lack of any CSS support whatsoever in Lynx is certainly a problem that I hope to put some effort into one day (and EWW – or rather SHR – isn’t much better in this regard), I’d like to note that I tend to use NoScript whenever possible, and thus I’m unsure if the “server push” feature these new protocols implement will actually result in quite as much saved bandwidth (or reduced latency.) I didn’t delve into the details as of yet, though.
    3. JFTR, I’ve checked the HTTP/1.1 headers of the Wikimedia responses, and their Cache-Control: has private and must-revalidate, but not no-store, which means (AIUI) that caching is possible, as long as the cache does not reuse a response sent to one client’s request to serve another’s (and also always uses an If-Modified-Since: request to check if the resource cached was updated.) Moreover, the logs for the MediaWiki instance I run myself indicate successful generation of the 304 status code, which indicates that at least the browser cache is properly utilized.
    Ivan Shmakov (dc) 18:00, 29 December 2015 (UTC)[reply]
    Well, I’ve lost the point entirely. As I read it, the whole idea behind sslstrip is to transparently proxy requests intended for http://example.com/ to https://example.com/ – and that only makes sense if the site in question has plain-HTTP support disabled (by the means of a redirect.) For one thing, this allows user agents lacking TLS support (Dillo had TLS support in the works the last time I’ve checked, and it’s certainly optional in Lynx) to be used to read Wikimedia sites, as well as a number of others. — Ivan Shmakov (dc) 14:25, 30 December 2015 (UTC)[reply]
  4. While I am certainly fine with this proposal - I've never had a Wikimedia-related password that doesn't meet these requirements - it is worthwhile to note that the discussion of account security arose out of a situation where administrators re-used passwords that they'd used on other sites instead of creating a fresh Wikimedia-only password. There have been all kinds of system hacks including password theft over the last several years, as we all know. However, there is no practical way to force administrator or higher-access accounts to have a password unique to their Wikimedia account. It's clearly Password Security 101, but even good people sometimes forget these things. Risker (talk) 05:10, 14 December 2015 (UTC)[reply]
    While the events at EN Wikipedia has caused a lot of attention to be focused on passwords, and really kicked this discussion into high gear, I would note, that this isn't entirely a reaction to the events at Wikipedia (And of course, this would not have directly prevented the events at EN Wikipedia, although it appears that at least one of those users had a password that would not meet the proposed requirements [6], so it might of indirectly prevented the incident in so much as the user would not be able to use the weak password that was shared on our site). The code for increasing min length was completed way back in June. It was turned off on Wikimedia pending having some sort of discussion about it[7]. Figuring out what sort of discussion to have kind of got pushed to the back-burner while other more critical things got priority. So this discussion is much over-due, and would have happened even without the incident on english wikipedia. BWolff (WMF) (talk) 08:30, 14 December 2015 (UTC)[reply]
    Maybe the WMF could ask the companies who make password managers to provide a whole lot free or discounted versions for active Wikipedians (or just admins/CUs etc.)? Perhaps a discount on LastPass Premium or a voucher code for 1Password. There's FOSS alternatives as well. Tom Morris (talk) 11:57, 21 December 2015 (UTC)[reply]
    Personally, I would think that FOSS solutions would be much more trustworthy for this type of application. BWolff (WMF) (talk) 12:03, 22 December 2015 (UTC)[reply]
    Dubious, given that closed-source solutions have a more effective business model, thus more programmer hours to improve security. There is some nice discussion about that in this (looong) thread. --Tgr (WMF) (talk) 04:36, 1 January 2016 (UTC)[reply]
  5. "Once the restrictions are put into place, users who don't have a strong enough password will be asked to change it next time they log in." To clarify: will this force the user to change the password before proceeding, or can they dismiss and ignore it each time? Equinox (talk) 07:33, 21 December 2015 (UTC)[reply]
    Initially they will be allowed to dismiss the warning every time (Although just having the warning will hopefully serve to entice users to do the right thing). Eventually once everyone is used to the warning and we're sure the warning has not caused any unexpected hardships, I believe the plan is to switch to a system where users will be forced to change their password to continue logging in, although I'm not exactly sure about the details about that switch. ( ping @User:CSteipp (WMF): Do you know better what the exact plans with that are?). BWolff (WMF) (talk) 09:07, 21 December 2015 (UTC)[reply]
    The mechanism we use currently just prompts the user each time they login, and they can continue to click "cancel" every time. We could expire their password when they have a non-compliant password, so they could click "cancel" until their password hard-expires, and then they would have to reset the password before they could complete their login. CSteipp (WMF) (talk) 21:25, 22 December 2015 (UTC)[reply]
  6. Isn't the ultimate solution for the problem described is to enable and enforce 2FA (two-factor authentication) for those with the rights? Kenrick95 (talk) 12:04, 21 December 2015 (UTC)[reply]
    2FA should not happen, as it currently is only practical through the use of cell telephony, which bears its own share of privacy risks – through being predominantly based on non-free software first, but also because of the very design of this particular communication medium. (For instance, RMS explains it briefly in http://stallman.org/rms-lifestyle.html.) — Ivan Shmakov (dc) 17:45, 22 December 2015 (UTC)[reply]
    rms has some odd views on passwords (Or at least did historically). Well cell phones are the most common means of doing 2FA, they are hardly the only one. It wouldn't surprise me if somebody sells dedicated hardware for TOTP. There's also command line TOTP programs you can use on your free-software filled GNU/Linux box if you so desire. BWolff (WMF) (talk) 20:58, 22 December 2015 (UTC)[reply]
    I do not share the entirety of RMS views, but I find it curious that we tend to offer password-less access to the machines intended to be used mainly by our students. Moreover, I do not oppose 2FA on principle, but rather what indeed is the most common means of doing it. (Although frankly, I don’t seem to understand the value of 2FA should both the password and the TOTP key happen to reside on the same host – which I believe is going to be the case for the most users, unless cell phones – or some dedicated hardware, presumably rare – are to be put into the mix.) — Ivan Shmakov (dc) 21:40, 22 December 2015 (UTC)[reply]
    Indeed, for best security, one wants totally separate machines for TOTP vs where logging in. But even if using cell phones, there's a high likelyhood at some point or another, people will log in to their cell phone (Assuming its a smart phone). There are still benefits to TOTP, even if on the same machine [e.g. in the case of password re-use, or poorly chosen passwords] BWolff (WMF) (talk) 23:03, 22 December 2015 (UTC)[reply]
    If we introduce two-factor, we should push for U2F as that eliminates the possibility of man-in-the-middle attacks. (This is a good summary of the various attacks and defenses around web authentication.) --Tgr (WMF) (talk) 04:36, 1 January 2016 (UTC)[reply]
    I do see your concern on using mobile phone (either via the less-secure SMS or via an authentication apps) but it is happening everywhere across the big sites (Microsoft, Google, Facebook, WordPress, Dropbox, etc). Just because there are no free software to do 2FA does not mean it couldn't happen. Kenrick95 (talk) 10:58, 31 December 2015 (UTC)[reply]
    That may or may not be true (of the above, I currently use Google Mail – no 2FA necessary, – and plan to try out WordPress.com as well), but I certainly hope that Wikimedia will not become “just another big site” in the foreseeable future. — Ivan Shmakov (dc) 18:42, 31 December 2015 (UTC)[reply]
  7. The length and complexity of the passwords isn't nearly as important as the number of guesses allowed from recognized and unrecognized devices. According to mw:Manual:$wgPasswordAttemptThrottle, the system defaults to allowing 1 attempt per minute. That's 1,440 attempts per day and 43,000 attempts per month. There's no reason to allow more than 10 attempts total from a device I've never used before, and no more than 20 attempts from a device I use regularly (recognized by cookie or IP). Secure the system first against attacks, then focus on password strength and 2FA. -- Dave Braunschweig (talk) 15:37, 21 December 2015 (UTC)[reply]
    Shared IP setups (be it a proxy or a NAT box) are not at all uncommon today, and so the or IP part above readily opens a way for a malicious party to use the limit suggested to deny access to a specific user on the same network (that is: using the same proxy or NAT), as long as the login of the latter is known. Hence, the applicability of this approach may depend on the user in question. — Ivan Shmakov (dc) 14:25, 30 December 2015 (UTC)[reply]
  8. The password list mentioned in this RfC contains only latin letters and arabic digits. Of the 10000 most common passwords only 3000-4000 are 8 bytes or longer, therefore the other 6000 should be replaced with common passwords from cyrillic, CJK, arabic and so on alphabets. — There is nothing said about using a unique password. I think accounts with additional permissions should be required to state to the foundation that they use a unique password (I know this RfC is about software and this cannot be enforced by software or otherwise, but there are already other policies that cannot be enforced). And the password change dialog should include a request to use a unique password for all accounts. — An echo notification should be added to display the number of unsuccessful login attempts to all accounts. — Passwords can be reset by requesting a new password by email. A hacker can wikimail an administrator with a plausible request and the answer email of the administrator will reveal the very email address this administrator uses to recover a lost password. The hacker can proceed with this approach until he finds one with a vulnerable email-provider. Therefore a security question should be asked, when an emailed password is used (mandatory for admins, opt-in for all accounts). --° (Gradzeichen) 18:51, 21 December 2015 (UTC)[reply]
    I had trouble locating a list of non-english common passwords. If you're aware of any, please let me know. The echo notice is a good idea. I've filed phab:T122123 for it. I've filed phab:T122124 for instructing users to use a unique password. I agree that email a new password is a potential weak spot, although I'm not sure if a security question is a good solution (Or if there is a good solution). See some of the comments at phab:T122013. BWolff (WMF) (talk) 11:45, 22 December 2015 (UTC)[reply]
    @BWolff (WMF): As my answer is somewhat lengthy, I have put it on this page: User:°/some ideas on common passwords. --° (Gradzeichen) 21:20, 22 December 2015 (UTC)[reply]
    100 most common Hungarian passwords. The approach used there (scan password dumps from published breaches which include emails and filter by domain) could easily be adapted to other languages. --Tgr (WMF) (talk) 04:36, 1 January 2016 (UTC)[reply]
  9. everybody realize we have better secure ballots for english arbcom voting, than the log-in to vote? or OAuth ? any reason this is not implemented for log-in other than inertia? Slowking4 (talk) 20:09, 21 December 2015 (UTC)[reply]
    Can you clarify what you mean by this. If I remember correctly, we use securepoll for arbcom (I think. Not an en wikipedian, so I didn't vote), which would PGP to encrypt ballots. Is that what you're referring to? Are you suggesting to use Public/private key pairs for authentication? (Client-side SSL certificates would be the logical implementation of that). I think its unrealistic to expect most users to be able to do that, given the current state of client-side SSL certificates on the web in general (Support exists, but I can't think of a single site that uses them). BWolff (WMF) (talk) 11:33, 22 December 2015 (UTC)[reply]
    i'm saying logon is the weak link. PGP is currently implemented for voting and OAuth. no reason it could not be implemented for bureaucrats, in time admins, and eventually editors. yes, making peer to peer encryption user friendly is the task, but it does not seem to me more off-putting than the current wall of captchas. see also w:Transport Layer Security - Slowking4 (talk) 15:58, 22 December 2015 (UTC)[reply]
    I think you're conflating encryption and authentication, which are really separate (but highly related) things. Encryption is making sure that nobody can eavesdrop, authentication is making sure you are talking to the right person. PGP Encryption in securepoll is primarily used for encrypting the votes. We don't really use it for identity management, or at least not in a way that really translates to logging in (A small users hold the decryption key for the list of votes, obviously). Key management in PGP is most closely associated with the web-of-trust model, which is rather inapplicable to our use case (Web-of-trust is kind of like verifying you're talking to the right person by playing 6-degrees of kevin bacon. For example, my key has six people who've vouched for it. If someone wants to talk to me, the hope is that they know one of the people who've (potentially transitively depending on how much faith you put in the internet) vouched for me). One can of course potentially use other key management models with PGP, which may translate better. The aspect of PGP that we primarily use in securepoll is the plain encryption facilities. The encryption facilities of PGP are roughly equivalent to the facilities in TLS. Both can support a variety of ciphers, AES being one of the most common. (TLS = Transport level security = The S in HTTPS). We use TLS to secure your password in transit so that nobody can eavesdrop on it. Specifically, when you submit a password, it is encrypted with TLS until it gets to the Wikimedia data center (If your nearest data center is a caching data center, the last leg of the trip is encrypted using IPSec). So in one sense, your password is treated with the same amount of encryption as securepoll votes are.
    Authentication involves proving who you are. Broadly speaking there are 3 ways of doing this:
    1. Something you know. Most typically this is a password, which is what we are doing currently. This method has the benefit of easy to change if someone finds out your secret. The con of this method is that humans are very bad at memorizing high-entropy secrets, and generally don't follow security best practices.
    2. Something you are. aka Biometrics. Not really directly applicable to us as we're not in physical control of the user's device. If someone wants to use biometrics, the typical workflow would be to use it to unlock some sort of private key, which would be entirely on the user end. The benefit to this method, is its hard to steal a biometric.
    3. Something you have. There's two subtypes here - First we have TOTP [Sometimes called OATH] (When you combine with a normal password, you get the system which many people mean when they say "2FA"). This is when you have an app on your phone, which generates a new random number every 5 minutes. To log in you need this random number. The random number is only good for about 5 minutes, so if someone steals it, they have a very limited time frame to make use of it. So in order for someone to impersonate you, they need to somehow steal/hack your phone. The people who are in a position to steal your phone are often not the same people who are in a position to crack your password. Requiring both makes it much harder to break someone's account. Supporting this method of authentication is on the roadmap for the future.
    The other approach to "something you have", is certificates (Or some sort of cryptographic keys). I think this is most likely the type of thing you are thinking of. In a web context, we're probably talking about TLS client certificate authentication (Sometimes referred to as TLS CCA, or TLS client-side certificates). This is where there is a file on your computer, and to log in to a site, your web browser uses this file (Sometimes the file is additionally password protected. Really paranoid people put the certificate on a smart-card device). One of the cool things about this method is that none of the secret material is ever transmitted to the server. All that's transmitted is enough to log you in a single time. So even if someone takes over Wikimedia servers, they can't compromise the original key. This sort of approach is popular in things like SSH (people with a tool labs account will be familiar with it), but really hasn't taken off in the web. The main issues are: getting users to understand certificates is complicated (much of the UI is kind of less than ideal. This is the sort of thing that has to be implemented in web browsers so we have no control over the UI), Very few people use it (although apparently its popular in estonia [8] ) so many of the server side implementations are less tested than one would normally like for security software (Some of the issues mentioned in this pdf about the mod_ssl implementation of CCA really raise red flags about the maturity of the implementation. Of course that's from 3 years ago...). Also, there is no standardized way of logging a user out when authenticating with this method (Which is just kind of insane). Last of all, certificates have to be installed in any web browser the user uses. This means that people would never be able to log in from a computer other then there own. I feel like a lot of people would object to such a restriction. Thus, well Client-certificate authentication has some very nice properties, I don't think its the best fit for authentication on Wikimedia. See also http://www.browserauth.net/tls-client-authentication . [This is just my personal opinion about the suitability of TLS-CCA. I haven't actually discussed it with other people, so there's a possibility that the rest of the WMF security team feels differently about it]. BWolff (WMF) (talk) 07:33, 23 December 2015 (UTC)[reply]
    i see there are “Authenticator” apps [9] and 'Yubico, is called a “security key,”' i.e. encrypted authentication. Slowking4 (talk) 17:32, 23 December 2015 (UTC)[reply]
    "Google authenticator" is just an implementation of the TOTP/OATH algorithm. It is highly likely it will be supported as part of the 2FA support that's getting added sometime in a couple months (Its already supported on https://wikitech.wikimedia.org, but there's still more work to be done in order to make it work on normal wikis, with SUL, and the UI experiance on wikitech is a bit rough around the edges). Yubico is a hardware token product most commonly associated with U2F. This is basically another way of doing 2FA (With even better security than TOTP. Actually probably the best security of any option I've ever heard of. Combines many of the cool properties of doing TLS CCA, without the stupidness, and all the key material is safely on a separate single purpose device, so very difficult to compromise.). Downside of course if you have to spend $20-$40 to buy a hardware token. And browser support is a bit shaky (But apparently is going to improve in the near future). While I don't think there's been any decision about what 2FA methods to support as of yet, I'm hopeful that U2F will be one of them. BWolff (WMF) (talk) 21:59, 23 December 2015 (UTC)[reply]
    TOTP link fix en:Time-based One-time Password Algorithm --TitoDutta 15:38, 24 December 2015 (UTC)[reply]
  10. BWolff (WMF) and other WMF guys, I can not understand this very well, why not impose this policy on everyone (or no one)? I agree with all those editors who have said experienced editors know well how to protect their accounts. --TitoDutta 15:36, 24 December 2015 (UTC)[reply]
    I'm only worried about accounts, which if compromised can do real damage that might not be easy to undo. A normal account can't really do much more than an anonymous user (Even with high but non-admin rights, the damage possible is order of magnitudes less than if people have admin). On the other hand, if someone compromises oversight/checkuser, they can retrieve very sensitive information which is impossible to make the malicious person un-see. If a malicious person takes over an admin account and has access to editinterface (What I'm really worried about), then that person can (for example), turn a Wikimedia site into a place to distribute computer viruses, extract private information from pretty much any user, and take over pretty much any other user account (including in certain circumstances, user accounts on wikis other than the compromised one).
    Ultimately restrictions like this have both a cost and a benefit. While the cost isn't all that high, its still annoying for some users to have to use secure password. What does it matter if someone who never edits and has an account only to say set language preferences in Special:Preferences has a secure account? It does matter if someone with admin rights has a secure password. BWolff (WMF) (talk) 16:47, 24 December 2015 (UTC)[reply]
  11. I should say that I Oppose Oppose apply this for local sysops, but Support Support for the rest, because I claim, the normal sysops should have right to be a white hat. --Liuxinyu970226 (talk) 10:47, 25 December 2015 (UTC)[reply]
  12. Generically supportive of this with the obvious exception that WMF should not target a single class of user. WMF should be concerned with the security/privacy of all user accounts, not solely those which - if compromised - might harm the WMF. - Amgine/meta wikt wnews blog wmf-blog goog news 17:25, 26 December 2015 (UTC)[reply]
  13. One thing seems to be missing in the proposal: how about accounts gaining additional rights in the future? A 'normal' user can have a single-byte password, now and in the future. What happens if this user becomes admin, checkuser of whatever, in the future? Although it's not a bad idea to change your passwords now and then, forcing users to change it when they gain these rights in the future is not part of the proposal. RonnieV (talk) 00:50, 28 December 2015 (UTC)[reply]
    If the user gets new rights, and their password doesn't meet requirements, they will be prompted to change their password next time they log in. BWolff (WMF) (talk) 06:59, 28 December 2015 (UTC)[reply]
  14. … Speaking of the Yair rand comment (15115192.) If my math is still good, there’re just 20,160 anagrams for “password”, and my guess is that the vast majority of them are not going to be blacklisted. Which may or may not have certain implications. — Ivan Shmakov (dc) 14:25, 30 December 2015 (UTC)[reply]