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)

Possible solution
We propose two parts:


 * 1) 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 bug 25925) 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)
 * 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, 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.
 * 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.
 * 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)