The University of Plymouth just published a study that states, "Leading internet brands including Amazon and Wikipedia are failing to support users with advice on how to securely protect their data..." One main point that was emphasized by TechCrunch is that Wikipedia accepts single-character passwords like “b”. That makes wikipedia.org the only top ten websites not to require a minimum password length. Although Wikimedia doesn't store nearly as much personal information as the other websites on the list, studies like this can give the impression that security isn't taken seriously for other elements of the sites (like credit [[ URL | card ]] donations). Eight characters seems to be a secure minimum password length, used by others including Google and Microsoft.
Description
Related Objects
- Mentioned Here
- T121181: Implement password policy preventing user using their real name
T122124: Tell users to use a unique password when creating an account and changing their password
T151425: Enlarge Popular Password File to 100,000 entries and enforce the new minimum in the config
T166622: Allow all users on all wikis to use OATHAuth
T188283: Display password policy information on Special:CreateAccount and Special:ChangePassword
T189641: Service for checking the Pwned Passwords database
T32574: Display a password strength bar
T20222: $wgMinimalPasswordLength's default should be 1
T121179: Implement password complexity password policy check
Event Timeline
This is an old topic. If you search this Phabricator installation for "password length", you'll find a bunch of related commits and tasks. There are also wiki pages such as https://www.mediawiki.org/wiki/Requests_for_comment/Passwords and mailing list posts about this.
I think we should be moving in the direction of making it even easier to create wiki accounts, perhaps not even requiring a password to be set at all. We could provide a text input box on the edit screen that allows someone to pick a user name or have one auto-assigned instead of using an IP address. We could support only entering a cell phone number or an e-mail address to make an edit. There are pitfalls to these approaches, naturally, but implementing some of them would likely be an improvement. We want people to edit and contribute to the sites. To this end, we continue to support logged-out editing to promote the culture of fast ("wiki") and easy contributing. In my opinion, encouraging editing and trying to reduce barrier to entry should be our focus, not security theater.
Amazon and Wikipedia aren't really reasonably comparable other than both being Web sites. Nobody uses a credit card to order items to their house off of Wikipedia. :-)
I get where you're coming from and agree that future password-less login technologies would be great. However, the technology is definitely not at a point where a system like what you're describing would be secure. Allowing users to pick a username by only identifying them using an IP address could lead to shared accounts and people vandalizing on others accounts. For example, I edit protected articles while at school, allowing others to piggyback on my account defeats the entire purpose of having them in the first place. I fully agree that the Wikimedia global account sign-up process collects far less personally identifiable information, in comparison to e-commerce sites. I brought up the credit card donations component as an example of something that could be negatively affected by a perception that Wikimedia has bad security practices.
The MediaWiki software itself offers https://www.mediawiki.org/wiki/Manual:$wgPasswordPolicy already. Hence removing MediaWiki-User-login-and-signup .
The Wikimedia settings at https://noc.wikimedia.org/conf/CommonSettings.php.txt define MinimalPasswordLength for specific wikis/groups.
Wikipedia accepts single-character passwords like “b”.
Historical reference: T20222
This very task might be blocked on T121179 plus (not sure) Community-consensus-needed .
FYI, the relevant part of the paper is linked from wikipedia weekly (and i have copy).
Can we set access policies on phabricator uploads ?
BTW related: T32574: Display a password strength bar
@TheDJ: See https://www.mediawiki.org/wiki/Phabricator/Help#Uploading_file_attachments - yes if you use https://phabricator.wikimedia.org/file/upload/ and have a "Visible To" dropdown shown there
this paper is quite outdated or even incorrect, except for "usability" - i.e. present a password strenght meter. to be more detailed, it says that a password is sent via email. but - this is only a temporary password which only allows to reset the password. so comparable to a link with some arbitrary number. it also suggests to use different character classes, which is discouraged by recent NIST research. it also thinks that a minimum password lenght should be set which is also against the NIST recommendations - which are clear that the type of the service offered, or the information to be protected, should determine the password strenght. also, NIST discourages policies that force to set a new password (regular password change eg) and suggests that the strenght should be measured against a list of breached passwords while the study says reusing an old password is bad - no matter if breached or not.
so - i would vote to close this ticket, and implement: T32574 as recommended by NIST. with it users can determine how secure their password should be.
the nist recommendations: https://pages.nist.gov/800-63-3/sp800-63b.html
As mentioned by @TheDJ, I linked a copy of the paper to the Wikipedia Weekly and Wikimedia Foundation social media hub private Facebook groups. If you would like to take a look at the study, email me via Meta-Wiki (https://meta.wikimedia.org/wiki/Special:EmailUser/Daylen) and I will share the PDF with you. The author has only granted permission for it to be used by Wikimedians/the Wikimedia Foundation, so please don't share the link publicly.
Indeed, it seems this was closed based on an erroneous assumption.
Where do the NIST recommendations discourage minimum length requirements? I haven't read the full document, but section 5.1.1.2 says this:
"Verifiers SHALL require subscriber-chosen memorized secrets to be at least 8 characters in length."
- which are clear that the type of the service offered, or the information to be protected, should determine the password strenght. also, NIST discourages policies that force to set a new password (regular password change eg) and suggests that the strenght should be measured against a list of breached passwords while the study says reusing an old password is bad - no matter if breached or not.
so - i would vote to close this ticket, and implement: T32574 as recommended by NIST. with it users can determine how secure their password should be.
the nist recommendations: https://pages.nist.gov/800-63-3/sp800-63b.html
Sorry, I don't choose the license terms. I'm just following what they stated. The publisher doesn't allow the study to be shared freely. The PDF is only meant to assess security issues, not to cite in articles. In case you would like to take a look at the study, I have emailed you a copy. Cheers, Daylen
I can access it fine personally as I happen to be a member of one of the institutions allowed to use the link in the description. My point is that development decisions generally get made in public, and not all Wikimedians have such access.
The email Steve sent me stated that the PDF should not be publicly accessible, but you can email them for clarification (S.Furnell@plymouth.ac.uk). I don't think the study needs to be included in a village pump discussion, just snippets that represent why there should be a password length requirement. I would also propose a password strength bar (Phab ticket mentioned above), but MediaWiki currently does not allow for this.
So does the paper actually say anything new? Users choosing terrible passwords is not new. The question is always a risk analysis question. Does the risk of users using stupid passwords outweigh the inconvineance of forcing good passwords? How does this vary with different classes of users? To what extent is it a personal responsibility vs how much of a threat is it to other users (esp. When talking about forcing strong passwords instead of merely suggesting them).
Im not saying we couldnt do better on this front, we certainly can. But knee jerk reactions create bad security systems which are often inconvinent and ineffective. We should start by analysing the risks we are worried about and then create security measures appropriate to the things we are worried about, not just blindly change things, and hoping it improves security.
(I have not read the paper)
the title "password meter" would not suggest a duplication. but the contents is a full ducplicate - and - has a lot more value. there is already an expert discussion in T32574: Display a password strength bar which includes password strenght. the patch attached to T32574: Display a password strength bar uses a password meter algorithm. it implements to configure a minimum strenght in the config file. it does not (yet) implement anything to show the complexity of the password to the user beforehand. having a second ticket only for the lenght of the password based on a paper of such weak quality which is not even public for everybody seems not ok. what mediawiki currently offers is already far better than described in that paper:
- https://www.mediawiki.org/wiki/Manual:$wgPasswordPolicy - password lenght 8 for different user groups already there
- limit the rate of retry in online attacks
- hash the passwords for offline attacks (not sure though if it is still in line with what NIST says ...)
the NIST is much more subtle and has a load of recommendations, most targetted to usability. taking out one arbitrary sentence seems not ok imo. the actual NIST recommendation is passwords "need to be of sufficient complexity and secrecy". this is the reason why my personal opinion is that a minimum password lenght of 8 for an arbitrary user (not sysop/burocrat/admin) in wikipedia is nagging the user.
for all these reasons i did close it as "duplicate" (invalid). which is not "not implement" / "declined" btw.
It doesn't - they repeat the same research every few years, I suppose they are trying to do some kind of State of the Password thing. Also they did not do a very thorough job, not realizing that Wikipedia has different password policies for different user groups. Still, it's a good prompt to reevaluate things, which is healthy to do every few years IMO.
Here's a summary of the criteria examined in the study, with the relevant tasks linked:
- show password requirements before the user would enter any password, so they don't have to guess then by trial and error (T122124: Tell users to use a unique password when creating an account and changing their password is somethat related)
- show guidance not only on what to do but also why to do it
- do these on each of registration, password change and password reset (T188283: Display password policy information on Special:CreateAccount and Special:ChangePassword is the closest)
- show a strength meter (T32574: Display a password strength bar)
- use minimum password length (T200052: Mandate that account passwords must be a minimum of eight characters on Wikimedia projects - we only do it for privileged users now)
- prevent use of user data as password:
- id (we do that already - presumably they mean username, not numeric ID)
- real name (T121181: Implement password policy preventing user using their real name, real names not enabled on Wikipedia though)
- prevent common passwords from being used (we only do it for privileged users, and even there not very effectively - see T151425: Enlarge Popular Password File to 100,000 entries and enforce the new minimum in the config or T189641: Service for checking the Pwned Passwords database)
- require multiple character classes (as noted by others, not really considered good practice today)
- prevent passwords that are dictionary words or very close to dictionary words
- prevent reuse of old passwords (not sure what this is about - at least in the excerpt they provided for use by Wikimedians, it is not explained, and I don't see what would be the point without some kind of forced periodic password change which is again questionable practice)
- extra protection such as 2FA (T166622: Allow all users on all wikis to use OATHAuth)
- password reset instead of password recovery (we do that)
A bit off scope for the task, but I'd argue MediaWiki defaults should be made significantly more strict (8+ characters, larger common passwords database), because we might base our use of weak password policy on a risk assessment, but most installs won't, and good software should code with secure defaults.
I think there are at least two password length related things that could be improved:
- Our concept of "sensitive" accounts (where a higher effort is put into protecting them). Currently we treat accounts with powerful user rights as sensitive; probably all users beyond some edit count should be (not sure how hard that is cross-wiki). People start with a cheap password as they consider their account not valuable, then forget about it when their account becomes valuable due to the time invested. Account theft is a not uncommon griefing method. We probably should not force strong passwords but at least warn people when they log in with a weak one and they have tens of thousands of edits.
- We tend to say we require long passwords for admins etc, but we actually don't; we just nag them on login if the password is short but we still accept 1-char passwords. I think we should hard fail on short passwords (or maybe set some kind of time limit, in case of newly promoted people, but that's harder to implement).
Probably way less important than 2FA, password reuse detection and attack detection, though.