Requests for comment/Passwords

This document proposes a change to the MediaWiki password policy and outlines other ideas for future discussion.

Context
MediaWiki's password policy does not currently require or encourage users to have very strong passwords. Consider the following:


 * The current minimum password length is only one character. At the risk of stating the obvious, this is unusual for the modern web. Whether a MediaWiki user is a farm of thousands of wikis, or a private corporate wiki, they are likely to want to have strong passwords for users, and length is a key determining characteristic of password strength.
 * We do not effectively suggest to users that they select a strong password, nor do we tell them what a strong password is. Current core login, password reset, or account creation forms either contain only a link to a help guide or nothing at all. Some wikis have used customization of MediaWiki messages on login or account creation to provide instruction about password security. Previous instructions have often been vague – English Wikipedia's signup form simply told users to "choose a strong password that would be difficult to guess". We can do better.

Proposed change
We're proposing the following simple change. While other ideas have come up in the past (see the Talk page or previous RFCS) this change is easy to implement and will not be an unexpected burden to the vast majority of users.

Increase $wgMinimalPasswordLength
The default setting (also used in Wikimedia configuration) for $wgMinimalPasswordLength is currently one character. This should be changed to a minimum of six bytes.

Until resolution of users were allowed to have blank passwords. Today, users will have experienced other applications and services which typically request long and complex passwords. While in the past it may have seemed a major annoyance to require a longer password, it now will be a requirement that users expect as part of registering. If we want to provide an alternative option with a lower barrier to entry then there is always editing while unregistered.

Increasing $wgMinimalPasswordLength will currently lock users out of their account, if they do not meet the minimum password length. These users will then be forced to use the password reset form. After is merged, we will be able to force a password reset without locking users out of their accounts. (Note: this will impact users of Wikimedia wikis before basically all others. Loud and numerous announcements before a switchover will be required to minimize annoyance to current account holders.)

Additional ideas for discussion
This request for comment is a merge and refactor of two older but closely related discussions:


 * Platonides created "Password strength" in 2010-12-20
 * Matt Flaschen created "Password requirements" in 2013-02-08

These two address basically the same set of problems, even if the solutions proposed were different. Some of the following ideas come from previous RFCs or research in to password strength. There may also be other ideas we have not considered yet, so please feel free to add to this list. The following are not necessarily proposed for implementation immediately, unless a consensus for them develops.

Create a password strength indicator
MediaWiki core forms for login, account creation, and password reset would benefit from a client-side indicator of how strong a user's password is. Even passwords that meet the minimum requirements may be weak, and so password meters are an extremely common UI pattern. There are some good pre-existing solutions to this, and we have tested client-side valiation in the past as part of the account creation user experience. This is easy to do, if  criteria for defining what constitutes weak or strong can be agreed on.

Require more complex passwords
Many sites require users to have passwords which mix letters, numbers, symbols and uppercase/lowercase characters. We need to explore the implications for non-English speaking users more here, and it may be unnecessary anyway.

Create new password requirements for accounts with advanced user rights
If we want new users to not be subject to annoying requirements that make signing up harder, then increasing password requirements only for accounts with advanced userrights might be a good future solution. However, further discussion is needed about how to implement this and for which userrights. This topic is probably more appropriate for a future request for comment.

Password expiration
Password expiration functionality is likely to be added, so that administrators can age passwords, or force users to reset their passwords on login. By default, MediaWiki will not expire passwords on any schedule. The security advantage of having password expiration available is as a contingency measure, if we suspect that our password database has been exposed or otherwise compromised.

Discussion

 * I'm ok with showing an indicator, but I oppose requiring stronger passwords. It is up to the contributor to choose in my view (forms which require things are a bit obnoxious; I would support that, were there existing issues with account takeovers). --Gryllida 10:01, 24 January 2014 (UTC)
 * There are. English Wikipedia has a list of admin accounts that were desysopped after being compromised.  At least some of those were probably due to password guessing.  And of course, there were probably more privileged accounts on other wikis (Wikimedia wikis and otherwise), and plenty of regular users, who were also compromised. Superm401 - Talk 23:32, 24 January 2014 (UTC)
 * Thanks for the context; I would still not want to enforce anything, for usability, and work out how to make the indicator sufficiently prominent. --Gryllida 00:24, 25 January 2014 (UTC)
 * Concur with Gryllida. Perhaps enforcement can be done per-wiki, but out of the box merely indicating weakness is all the software should do - David Gerard (talk) 20:04, 24 January 2014 (UTC)
 * In this case, we're discussing what the MediaWiki default for the minimal password length is, not necessarily what all individual wikis will do. To be frank, I personally think this is something where Wikimedia wikis are going to just need to eat their peas, considering there is nearly universal requirement for a password more than just one character on modern websites. But in theory it is possible for us to set different configurations for different wikis. Steven Walling (WMF) &bull; talk   20:17, 24 January 2014 (UTC)
 * MediaWiki core should have sane defaults, which include a reasonable minimum password length. Wikis can still override that default. Superm401 - Talk 23:32, 24 January 2014 (UTC)
 * I agree with this. MediaWiki should provide sane defaults out of the box, and that includes a half-decent password length requirement (something low like 6).  Kudu ~I/O~ 19:58, 25 January 2014 (UTC)
 * Superm401, Steven Walling (WMF), thanks! Out of curiousity, what process would prevent a new MediaWiki default from being imposed onto all Wikimedia projects? --Gryllida 09:13, 26 January 2014 (UTC)
 * This is beyond the scope of the RFC. However, In my opinion, the default for Wikimedia wikis should also be at least 6 for all wikis.  Superm401 - Talk 02:21, 28 January 2014 (UTC)
 * On a side note, I don't find «this would be a MediaWiki default, not a Wikimedia project default» a compelling argument. The interface should still be as good as possible, however community defines «good». --Gryllida 09:13, 26 January 2014 (UTC)
 * How many more users would be locked out if we made the minimum password length 8 characters instead of 6? The  helpful  one  20:22, 24 January 2014 (UTC)
 * We do not store password length, so there's no simple way to answer this question. Superm401 - Talk 23:32, 24 January 2014 (UTC)
 * Okay that's reasonable enough, it's just that our own page about this suggests a minimum of 8 characters, as does (from a quick search) this Google page and this one from Microsoft. If we're going to try to fix the issues with the password lengths at the moment, then perhaps we should add the two extra characters for the minimum length as well? The  helpful  one  23:37, 24 January 2014 (UTC)
 * Ultimately this is a somewhat arbitrary choice. Longer passwords of any type will always be more secure than shorter passwords. But there is an obvious tradeoff between greater security and annoyance to users. Steven Walling (WMF) &bull; talk   21:22, 25 January 2014 (UTC)
 * I would like to see a way for us to require different password strengths based on a user's privileges. I have a horrible suspicion that several sysop accounts have "1234" and the like.  Privileges come with responsibility, and i think it's reasonable that one of those responsibilities is "protect your account".--Jorm (WMF) (talk) 21:08, 25 January 2014 (UTC)
 * Chris tells me that after is merged this will be technically feasible, since it will be possible to subclass the password object etc. I mostly did not propose it here for immediate implementation since I think the thing we need to get consensus on is starting with a sane default for MediaWiki's minimal password length. Steven Walling (WMF) &bull;  talk   21:19, 25 January 2014 (UTC)
 * thanks for this proposal. what i trap into consistently since years is not beeing logged in, when i want to. i'd really appreaciate if this is shown clearly, on all wiki's. i never can remember which ones indicate it and which ones not. mediawiki.org indicates it, btw ... and i was trying to comment there not logged in :) it would be great to tell where to report that this notification should be made default. --ThurnerRupert (talk) 22:06, 25 January 2014 (UTC)
 * for the password policy: display a strength indicator is great. anything more? i would say just leave it to the user (the system administrator, how he sets his sites default). --ThurnerRupert (talk) 22:06, 25 January 2014 (UTC)
 * Agree with Gryllida. An indicator could be useful (though in my experience people can be really good at ignoring such things), but password requirements are terrible. They're basically just a pain in the arse and annoying to the user, and outside of very specific instances rarely even work. Require a combination of letters and numbers? They'll add a 1 to the end. Require non-dictionary words? Require a certain length? They're more likely to just forget, and have to write it down somewhere, or even better yet, simply wind up using the same stronger password everywhere because it's the only stronger one they remember. And even if the user has a strong unique password that they memorise, and do everything right with it, that still may not be enough - someone could get on their computer physically, steal a cookie, use a keylogger, or find the password through a bug/oversight on the host end... it's not worth the hassle. Sometimes accounts get compromised, and and it's not even that hard to deal with it, whether it's Wikipedia or Illogicopedia or Stan's backend parts listing. We do not want to ship this as a default with core, or use it here; others may have stricter requirements for whatever reason, but they should be able to set that themselves. --Isarra some day, some time, and apparently VE is making me act like Aleister now.
 * Good thought about people maybe deciding to use same complex password everywhere, thank you Isarra! One would wish it could be possible to test... --Gryllida 09:13, 26 January 2014 (UTC)
 * There's a lot of talk about being annoying to the user, but I think an important point here is that we are not making a black and white decision. It's not like we have to choose between "passwords longer than one character" and "password between 6 and 14 characters with at least one number, special character, and capital letter, and does not match the user's email, phone number, social security number....". The decision is what level of password requirements we implement. I think raising the minimum password length to something like 4 or 6 characters is not that bad. If you are using passwords that short, you should not be using the Internet. And then to supplement that, we could have a non-binding indicator, as suggested, that shows password strength but does not enforce it. Parent5446 (talk) 04:45, 26 January 2014 (UTC)
 * Would password length be the same for all languages/charactersets - just "number of characters" - or is there any reason to vary it? (I presume it would be the same for all charactersets, for simplicity's sake.) User:Sharihareswara (WMF), Sun 26 January
 * My understanding is that yes, it will be the same. Steven Walling (WMF) &bull; talk   23:37, 26 January 2014 (UTC)
 * It is actually "number of bytes", since it uses strlen. I think this is probably okay for now, since languages with multi-byte characters often have more entropy per-character. Superm401 - Talk 02:33, 28 January 2014 (UTC)
 * Do we know about how often Wikipedia users change their passwords right now? Also, how many people would (if we reset their passwords) be effectively unable to log in, because they've never given us a working email address? User:Sharihareswara (WMF), Sun 26 January
 * I'm in favor of showing people a strength/weakness indicator, in favor of *having* an expire-a-user's-password-right-now ability to use if we suspect a password was compromised, in favor of more stringent requirements for users with advanced user rights (but how do we enforce that? upon receipt of new rights, the user has to re-log-in, and at that point we administer the stringency check?) and feeling unsure about minimum strengths and lengths because of others' arguments above. User:Sharihareswara (WMF), Sun 26 January
 * Requiring passwords to be stronger is a good thing. It's annoying to deal with complex passwords, but it's much more annoying to lose your account to an attacker because they got your password and then reset your email address. Of course there's also the problem that we don't require email addresses, so with complex passwords it's a lot more likely that users will set something more complex, never set their email address, then get permanently locked out of their account. We should definitely make it more prominent to users that not setting their email address is dangerous. In fact, we should remind them of this every time they log in.--Ryan lane (talk) 20:30, 26 January 2014 (UTC)
 * Password "strength" requirements are the bane of real security. Every character-class based algorithm I've seen has negative effects (force l33tspeak passwords, which dictionary attacks have a field day with) and breaks actually strong passphrase-based secrets.  By all means, puts a pretty 'complexity' bar to guide users, but don't enforce naive limits on passwords unless your algorithm actually calculates the real entropy (pro tip: you can't, it's AI-complete).  &mdash; Coren (talk)/(enwp) 15:11, 27 January 2014 (UTC)
 * If you read the RFC carefully, you can see that we're not proposing a password complexity requirement right now. We're only proposing an immediate change to the minimum length (from one char to six, or something else people will support if necessary). Everything else is still in the idea stage, though as you say, it seems pretty uncontroversial to also provide a meter suggesting whether passwords are weak or not. Steven Walling (WMF) &bull; talk   17:06, 27 January 2014 (UTC)
 * I think Coren's point is that proposing an increase in minimum password length is proposing an increase to password complexity requirements. I agree with him on that. That said, I disagree with him in that I don't think it's a bad thing. --Deskana (talk) 17:31, 27 January 2014 (UTC)
 * Yes, but a small increase in length still allows long passwords that don't use multiple character classes (e.g. XKCD-style passwords). Superm401 - Talk 02:21, 28 January 2014 (UTC)
 * Support increasing minimum password length to 6 characters. This is a simple change that only affects users with incredibly weak passwords. Some napkin maths I did showed that it'd take well over 100 years for a brute force algorithm to try every six character password combination, so I'm okay with a small increase in password complexity as a tradeoff. Also support a password strength indicator, as that really doesn't hurt anyone and may provide useful information to users. --Deskana (talk) 17:31, 27 January 2014 (UTC)