Requests for comment/Password requirements

This is to discuss changes to MediaWiki's default password requirements, and making them more configurable.

Context
MediaWiki has a default password minimum of only one character (Manual:$wgMinimalPasswordLength), which applies regardless of what user group (admin, steward, etc.) you are in.

Problem
This is very weak in general. Further, the Wikimedia rate limits make it possible to brute-force weak passwords online) (25925).


 * Isn't a clearer statement of the current problem that an already installed wiki with live users cannot increase the length of $wgMinimalPasswordLength without locking out existing users. A wiki that wants to become more secure cannot without nuking a large number of unprivileged accounts in order to force a small number of admin accounts to be more careful. LWelling (talk) 16:30, 11 February 2013 (UTC)
 * LWelling, assume we let wikis increase wgMinimalPasswordLength without locking anyone out. How does that deal with existing admins/crats/stewards with weak passwords? Superm401 - Talk 06:04, 12 February 2013 (UTC)
 * It does not, but it is not clear from the description of context and problem here why addressing it is not a trivial change to a default value. The problem is more complex than the default being too short, but you need to read the bugzilla tickets to get that. LWelling (talk) 15:30, 12 February 2013 (UTC)
 * Increase the password length requirement, then post a notice on the login page explaining what was done and that users should reset their passwords if the are affected. ఠ_ఠ  Inquisitor Sasha Ehrenstein des Sturmkrieg Sector (Talk) (Contr) 02:50, 17 February 2013 (UTC)
 * As probably noted in bugs elsewhere, the issue with this is that not all users have email set, which means that if they are locked out of their account, that's it for them. We could start with a warning on the log in page beforehand, of course. Steven Walling (WMF) &bull; talk   02:25, 19 February 2013 (UTC)
 * In order to inconvenience users like this, you'd need pretty solid justification. In this case, there seems to be little evidence of an actual problem. There's a theoretical problem, but in reality, is there a password security issue on Wikimedia (or MediaWiki) wikis? Is there data about this? --MZMcBride (talk) 10:41, 19 February 2013 (UTC)
 * The idea that a password of 1 character is secure is so outside the realm of possibility that the suggestion that we need Wikimedia-specific data to prove the point seems ridiculous. Now, if we wanted to quantify how much better or worse our password strength might be based on some particular change in requirements, that would be great to have data on. But to be honest I'm perfectly comfortable taking a recommendation from Chris Steipp and using the fact that this requirement comes from Wikimedia's sole security engineer as the justification. This was how it was increased to 1 character from null previously, IIRC. Steven Walling (WMF) &bull; talk   21:28, 19 February 2013 (UTC)
 * What are you trying to secure? Something like 99.99% of accounts are valueless. You're willing to trade convenience for what, exactly? Has Chris Steipp made any formal recommendations in this area? He doesn't seem to have participated in this RFC and only made one comment on the relevant bugs (25925, in which he doesn't seem to discuss changing the minimum password length). And you don't seem to recall correctly. It was previously possible to not have a password at all. The one-character minimum was implemented following 621 in response to an actual problem. Is there an actual problem here? Are there relevant bugs describing MediaWiki or Wikimedia accounts being hacked? Such bug reports might provide some justification for a change here. Otherwise, what problem exactly are you trying to solve? --MZMcBride (talk) 05:22, 21 February 2013 (UTC)
 * If you don't see letting people set a one character password as an obvious flaw to fix, I'm really not going to try and convince you. Steven Walling (WMF) &bull; talk   19:17, 21 February 2013 (UTC)

Possible solution
We propose two parts:


 * 1) The code will be changed such that Manual:$wgMinimalPasswordLength will be enforced only on password changes and for new accounts.  This allows increasing it to a larger value (more typical of the modern web) without locking anyone out or requiring regular users to change their password (it can still be encouraged).
 * Just a note: an RFC here is fine for consensus for MediaWiki development, but it cannot dictate how Wikimedia wikis choose to set this variable. It looks like Wikimedia wikis currently use the default from DefaultSettings.php, so this will need to be made explicit on the Wikimedia side before it can be changed in DefaultSettings.php, I think. I'm also not sure why you wouldn't also catch a change in minimal password length on user login (in addition to new accounts and password changes). --MZMcBride (talk) 20:59, 8 February 2013 (UTC)
 * People (including you on ) are rightly concerned about locking out existing users. The idea of this proposal is that existing regular (no special groups) users don't have to change their password when the requirements for new passwords (new accounts, password changes) change. Superm401 - Talk 23:36, 8 February 2013 (UTC)
 * Default settings and WMF settings. Resistance on WMF wikis is not a rationale to hold back changing settings in DefaultSettings. Any change to default settings that WMF wikis do not want can be overridden in WMF's settings. It's always been that way. There is no reason to hold back the raising of the default. Daniel Friesen (Dantman) (talk) 21:10, 8 February 2013 (UTC)
 * This is not true. User::checkPassword has a check to make sure the password is valid before authenticating, so raising the minimal password length will completely lock users out of their accounts and force them to use the reset password feature (assuming they have an email address set). Parent5446 (talk) 22:23, 11 February 2013 (UTC)
 * This proposal is to change the current behavior that you describe! vibber's comment in User.php (added in r9312 in 2005) makes it sound like the behavior is intended to check MediaWiki password validity in addition to external password authorization. Even if it's needed it could be moved inside wgAuth->authenticate check and/or be controlled by a global, triggered by a hook, etc. -- S Page (WMF) (talk) 00:38, 13 February 2013 (UTC)
 * Agreed. The proposal could  be the default behavior, and we can provide a global that wikis can change if need be.  But I'm not clear why having external password requirements implies a need to always check MW's requirements at login. Superm401 - Talk 05:31, 13 February 2013 (UTC)
 * 1) Password complexity requirements by group (44788).  This would be configurable and available for any group, but for instance admins would by default have more stringent password requirements than regular users.  If a user with a weak password were added to a new group with such requirements  logs in and does not meet their group's password requirements (edited), they would need to change their password on login before doing anything.  The "change password on login" requirement would not apply to users without such groups (even if wgMinimalPasswordLength changes).
 * Something, perhaps, to keep in mind: https://xkcd.com/936/ Anomie (talk) 15:36, 11 February 2013 (UTC)
 * Part 2 seems like two parts. 2A build a "require password change on login" feature, and 2B "enable per-group password length requirements".  2B seems hard to implement, hard to explain to users and in an edge case very annoying to a user.  It would be very frustrating to a user to be asked to change to a 6 character password one day, then to a 10 character one the next day.  I'm also not sure 2B addresses a real problem.  Are there really wikis out there that given the option would leave unprivileged accounts at minimum 1 and only increase admin accounts, or increase both to different levels? As long is the increase does not lock out existing users I'd expect most wikis to either continue to ignore security or increase it for all accounts equally. LWelling (talk) 16:48, 11 February 2013 (UTC)
 * I agree that we should just have a password requirement for all users, but in the interest of this feature, 2B would not be hard to implement. All that would be required would be to check if the password authenticates first, and then if the password is not valid, redirect them to Special:ChangePassword. Parent5446 (talk) 22:23, 11 February 2013 (UTC)
 * LWelling, the reason they're grouped into 2 is because only group members would have to change on login. I agree that 2B is not unduly hard to implement.
 * People do not generally sign up for a wiki Monday, become admin on Tuesday, then steward on Wednesday (on small wikis, they may start out admin). You're exaggerating the inconvenience.  Generally, if someone is trustworthy enough to be an admin, they're not going to balk at having a reasonable password.  The problem is that we *want* to let wikis lock out admins with very weak passwords.  For an editor, it's tolerable to let them keep a 1-character password indefinitely, even though we can advise against it.  There's not really much reason to tolerate that for admins; it's just right now there's no way to distinguish. Superm401 - Talk 06:02, 12 February 2013 (UTC)
 * User groups are not static, right? They vary depending on config and version, right? Therefore for 2B, you'll need to go from checking a single variable, to having a set of preferences stored the groups on your install.  Perhaps "hard" was a poorly chosen description, but going from a single static setting to a set of dynamic settings would be significantly more effort than changing the handling of the existing single value.
 * Correct, they are not static. There is a default set of groups, and wikis can override it.  But I don't think we should require an override.  If you choose not to configure a particular group, it would default to the main wiki configuration. Superm401 - Talk 05:31, 13 February 2013 (UTC)
 * That work would not seem worth it just to allow different groups to have different password strength. However, I do see a real motivation for different enforcement based on group. Allowing editors too keep their old short passwords may be acceptable to avoid disruption, but selectively forcing some groups to change at next log in would be a good feature.  From the comment by Superm401 that sounds like it may be the intention.  The proposal should be edited to say that. Users should not just be made to change when promoted to a group.  They should also be made to change on next log in if they are already in a group with elevated privileges.
 * Correct, there are two main intentions. 1. Allow stronger requirements for regular users going forward (while grandfathering in existing editors with no extra rights). 2. Allowing wikis to enforce hard group-specific requirements so people with extra rights are not compromised as easily. I agree it should be enforced at all times (no grandfathering in people if they're in elevated groups), not just at group change. Superm401 - Talk 05:31, 13 February 2013 (UTC)
 * Are you suggesting having one set of requirements, but only enforcing it for people not in the default groups? That could be workable, but there might still be a temptation to have lax requirements so as not to inconvenience regular editors. Superm401 - Talk 05:31, 13 February 2013 (UTC)
 * Thanks for the edit. That seems much more compelling to me.  But yes, if it were my proposal it would be that we keep a single length for $wgMinimalPasswordLength, change the default to 6 (as that seems to be the minumum elsewhere), by default grandfather in accounts that have shorter passwords and have a configurable list of groups that will be required to change their password on next log in if it is too short. The proposal as written meets it's goal, but I think upping the minimum for new editor accounts but not inconveniencing unprivileged grandfathered accounts is a better way of doing that than leaving the editor minimum at 1 and only increasing the minimum for select groups. LWelling (talk) 17:57, 13 February 2013 (UTC)
 * 2A would still be separately useful as a compromise. Allowing wikis to force future registrations to have a reasonable password without locking out users is still a good thing.  Fewer vulnerable accounts over time is the equivalent of stopping the bleeding. Currently we can't even do that. LWelling (talk) 15:23, 12 February 2013 (UTC)
 * Anomie, I'm not sure what your point is. I'm not proposing mandating any particular scheme.  The goal is the make the requirements configurable.  It's possible some wikis might choose to e.g., require at least one digit, or one space, but others would just say admins had to have 8 or more characters in their password.  Length alone would be a great start. Superm401 - Talk 06:02, 12 February 2013 (UTC)
 * Anomie is referring to the fact that the usual concepts applied to password security are considerably less likely to result in a secure password than a password made up of four random words. In particular, passwords that require the mixture of uppercase, lowercase, numbers and symbols are almost always impossible for the user to remember, so they wind up being written down or stored in either an easily compromised location or in a location that is only accessible under very particular circumstances (e.g., the browser password keeper on a specific computer). Alternately, people may create one such password and then use it everywhere so they only have to remember the one. I don't think there would be any significant objection to increasing the minimal length of a password, perhaps up to 6 characters; however, I think there are very valid objections to requiring passwords to have a mix of cases, symbols and numbers. In particular, I'd avoid requiring symbols entirely.  Risker (talk) 21:18, 12 February 2013 (UTC)
 * I agree special symbols are not really necessary, and the implementation could probably just start with different lengths by group (and no enforcement at login if there isn't a group-specific requirement). Superm401 - Talk 05:31, 13 February 2013 (UTC)