Jump to content

Requests for comment/Passwords

From mediawiki.org
Tracked in Phabricator
Task T95784
Request for comment (RFC)
Passwords
Component General
Creation date
Author(s) Steven Walling
Document status accepted
Approved in RFC review 2014-03-05 by Brion and Tim. -- Tim Starling (talk) 22:47, 10 March 2014 (UTC)[reply]

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

Context

[edit]

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.

Threats

[edit]

To clarify the threat model, here are some reasons a person may want to compromise different types of accounts:

Regular User Troll (in various ways) the user who was compromised; Spam/Vandalism edits as autoconfirmed user, avoiding many AbuseFilter rules; Email spam to other wiki user's emails (avoid the per-account limit)
Sysop Troll; Cause damage to the site (hostile code in Common.js) ; Spam/SEO (adding link in the interface)
Oversight/Checkuser Access to private data

Assuming an attacker does not have access to the database of password hashes, they are limited to online brute-force attacks. These attacks are limited in two ways, a throttle in core and by CAPTCHAs with ConfirmEdit.

Tracked in Phabricator
Task T122164

In MediaWiki core, $wgPasswordAttemptThrottle limits login attempts to a certain number of tries per time period. By default this is 5 attempts per 300 seconds. The counter for $wgPasswordAttemptThrottle is a memcache key based on the IP address and the attempted username, so if an attacker is simply trying to harvest accounts to use for spam on a wiki with millions of users, they can only test the same user account once per minute, but can try thousands of different accounts in parallel. It takes roughly 800B sent/6.5kB received to check a login using the login page (may be less using the API?), so it's not unreasonable to assume attackers who can brute force hundreds of accounts in parallel, and could search the entire 1 lowercase letter password space for all of these accounts in 26 minutes.

MediaWiki's core login throttle makes attempting to brute force a single account name more difficult for an attacker who is limited to a single IP address. However, since many antispam countermeasures on the wiki (such as TorBlock) allow users to login through the proxy, an attacker can brute force passwords through any of these systems. An attacker could potentially open a connection through all of Tor's exit nodes and try thousands of passwords for a single username each minute. Since the WMF does not keep http sessions open with Vanish, each connection has 532B for IPv6 (412B for IPv4) of connection setup, however an attacker could maintain over 1000 separate connections with a fairly average (10Mb) connection. If the attacker is targeting a small list, the usernames can be attempted in parallel on each proxy, so brute-forcing the entire list of sysops is limited only by the attacker's bandwidth.

In the ConfirmEdit extension in use on WMF wikis, there is an additional constraint that each IP address can fail authentication only $wgCaptchaBadLoginAttempts times (default is 3) every $wgCaptchaBadLoginExpiration time periods (default is 5 minutes) before needing to solve a CAPTCHA in order to login. Due to the design of the current system configuration, this does not prevent brute forcing except to require that users download the current CAPTCHA for each attempt—an overhead of 8-14kB, after a non-trivial amount of pre-computation.

Assuming an attacker has a fairly large amount of bandwidth, they can brute force about 43,000 passwords per month, per ip/proxy that they have access to. It's not unreasonable to assume attackers who can use 1000 proxies, so exhaustive search of all 6 lowercase letter passwords would take only 7 months. Requiring 1 uppercase and one number would require 1320 months to complete.

When performing offline attacks against passwords, the best attacks start with millions of common passwords and check permutations of these to brute force the hashes. This is significantly more effective than exhaustive search against most hash lists. See for example the stats and conclusions of "How effective is a straight dictionary attack?".

Proposed change

[edit]

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

[edit]

The default setting (also used in Wikimedia configuration) for $wgMinimalPasswordLength is currently one character. This should be changed to a minimum of six bytes.[1] This is implemented in Gerrit change 117635.

Until resolution of bug 621 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 Gerrit change 77645 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

[edit]

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

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

[edit]

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.[2][3] There are some good pre-existing solutions to this,[4] 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

[edit]

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.[5][6]

Create new password requirements for accounts with advanced user rights

[edit]
Tracked in Phabricator
Task T94774

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

[edit]

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.

Footnotes

[edit]
  1. ↑ The strength of a password six bytes long depends partially on the method of attack (offline versus online), as well as on the symbol space. Passwords with numbers, case sensitivity, and symbols make a difference. See the Wikipedia article on password strength and [1]
  2. ↑ http://ui-patterns.com/patterns/passwordstrengthmeter
  3. ↑ http://arstechnica.com/security/2013/05/its-official-password-strength-meters-arent-security-theater/
  4. ↑ https://github.com/lowe/zxcvbn
  5. ↑ http://blogs.mcafee.com/mcafee-labs/password-policy-length-vs-complexity
  6. ↑ https://xkcd.com/936/

Discussion

[edit]
  • 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)[reply]
    • 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)[reply]
    • I agree with Gryllida here. We can encourage better (read: stronger) passwords without requiring stronger passwords for unprivileged accounts. Ultimately, it's a user's choice how secure his or her account should be. And no amount of code can stop a user from (for example) writing his or her password down on a Post-It note, a practice that becomes more common as password requirements increase. --MZMcBride (talk) 21:25, 30 January 2014 (UTC)[reply]
      • It behooves the MediaWiki development community to provide sane defaults for account security, per the recommendation of security engineers, ops, and others. If a particular wiki feels account security is not important and wants to lower the default, they may do so. This is hardly a burden on users who will be subject to the default, considering the vast majority of websites require such minimum lengths. It's just common sense at this point. Steven Walling (WMF) • talk 04:00, 31 January 2014 (UTC)[reply]


  • 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)[reply]
    • 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) • talk 20:17, 24 January 2014 (UTC)[reply]
    • 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)[reply]



  • 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)[reply]
    • Chris tells me that after Gerrit change 77645 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) • talk 21:19, 25 January 2014 (UTC)[reply]


  • 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)[reply]



  • 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.


  • 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)[reply]



  • 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)[reply]


  • 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). — Coren (talk)/(enwp) 15:11, 27 January 2014 (UTC)[reply]
    • @Coren: 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) • talk 17:06, 27 January 2014 (UTC)[reply]


  • 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)[reply]
    • Deskana: I think there's common agreement that most user accounts (probably over 99%) are unprivileged accounts. Can you explain the need to secure such accounts? If I choose "wiki" to be my password (or the letter "j"), isn't that my choice as a user? What benefit is provided to either Wikimedia wikis or me by forcing me to choose a longer password? --MZMcBride (talk) 21:17, 30 January 2014 (UTC)[reply]
    • Software such as oclHashcat can try in excess of 10 billion md5 hashes per second on a single GPU. Dedicated boxes with 8 gpu's have been recorded at over 80 billion md5 hashes per second. Over estimating with 127^6 possible passwords and 10B/s gives us a ballpark of 6 minutes, with a lower bound in the "press enter and its done" category. I do think a minimum of 6 is better than the current situation, but far from being secure. EBernhardson (WMF) (talk) 21:30, 4 February 2014 (UTC)[reply]
      • Yeah, except we have a rate limit on password attempts. Does that software get around rate limiting? (The situation in which someone gets unrestricted access to the user table is clearly not in the scope of this RFC.) Steven Walling (WMF) • talk 03:23, 6 February 2014 (UTC)[reply]


  • While we're here, can I stick up for my favourite pet project: Password requirements printed somewhere useful. If you're going to require 8 characters, fine, but please _document it_ on the page. In fact, document that any character is allowed and that no length is too high. That way people with password generators can easily set their requirements in the software menus and not have to guess. --MarkTraceur (talk) 01:43, 1 February 2014 (UTC)[reply]



  • I also oppose enforcing a strong password policy. We aren't a bank, we're an encyclopedia. If we enforced a strong password policy, we would also have to require associating an email address (otherwise we would be inundated we people complaining about being locked out of their account), that would deter account creation, especially for people who want to protect their anonymity. Kaldari (talk) 18:16, 4 February 2014 (UTC)[reply]
    • Uh... we're not just talking about Wikipedia here. We're talking about the MediaWiki default. And even if were just talking about Wikipedia... yes, we're not a bank. That's why we're not adding a PIN code, PCI compliance, and a requirement to use an 8-digit password with mixed numbers, cases, and symbols. We're simply saying you shouldn't be a complete idiot and use a 1 character password. Steven Walling (WMF) • talk 04:30, 5 February 2014 (UTC)[reply]





(This editor is not mobile friendly; even after loading this text box lags a lot, suspect too js heavy). I wanted to leave a note that a change like this could have to also be done in the mediawiki installer where the first user password is set.

And requiring would mean that whoever wants to play with a test MW instance with collegues sharing a lan would have to either set a strong password - I very rerely do that for test vms and stuff - or figure put what setting to change; configuration learning curve is steep enough as is. --Gryllida 11:27, 10 February 2014 (UTC)[reply]

  • A 6-character default minimum seems sane to me. Regarding #Threats, $wgPasswordAttemptThrottle's default value is misleading, because it only functions when $wgMainCacheType is set to a non-default value. In practice, it's likely that most third-party wikis are completely unprotected against brute-force attacks (except to the extent that they can only handle a few requests at a time anyway :-)). —Emufarmers(T|C) 04:53, 12 February 2014 (UTC)[reply]
Emufarmers, you appear to have not read the discussion above. Imposing a hard limit is a torture of users where you can soft-encourage them by showing a meter. Please meditate on this point. Thanks. Gryllida 00:45, 14 February 2014 (UTC)[reply]

Is there a maximum length for a password in the software? Some users are now using 64byte passwords. — Preceding unsigned comment added by 75.109.120.249 (talk • contribs) 17:36, 8 February 2016 (UTC)[reply]

No. The passwords are hashed (currently using PBKDF2), which transforms passwords of whatever length into 128 bytes of data. After base64 encoding and addition of metadata, it comes out to 222 bytes stored in a 255-byte database field. Anomie (talk) 14:18, 9 February 2016 (UTC)[reply]
Retrieved from "https://www.mediawiki.org/w/index.php?title=Requests_for_comment/Passwords&oldid=4724710"