Page MenuHomePhabricator

Mandate that account passwords must be a minimum of eight characters on Wikimedia projects
Closed, InvalidPublic

Description

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.

Event Timeline

Daylen created this task.Jul 20 2018, 12:14 AM
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptJul 20 2018, 12:14 AM
Daylen renamed this task from Mandate that account passwords must be a minimum of eight characters on Wikipedia projects to Mandate that account passwords must be a minimum of eight characters on Wikimedia projects.Jul 20 2018, 12:14 AM

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. :-)

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.

Cirdan added a subscriber: Cirdan.Jul 20 2018, 8:59 AM

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 .

TheDJ updated the task description. (Show Details)Jul 21 2018, 8:41 AM
TheDJ updated the task description. (Show Details)
TheDJ added a subscriber: TheDJ.EditedJul 21 2018, 8:43 AM

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

Can we set access policies on phabricator uploads ?

@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

ThurnerRupert added a subscriber: ThurnerRupert.EditedJul 21 2018, 1:30 PM

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

ThurnerRupert closed this task as Declined.EditedJul 21 2018, 1:38 PM

duplicate of T32574 - there is a patch which implements password lenght attached to T32574. this does not display yet a password meter.

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.

Reedy added a subscriber: Reedy.Jul 21 2018, 6:57 PM

duplicate of T32574 - there is a patch which implements password lenght attached to T32574. this does not display yet a password meter.

I'm not sure how this is a duplicate of T32574: Display a password strength bar...

The author has only granted permission for it to be used by Wikimedians/the Wikimedia Foundation, so please don't share the link publicly.

Sounds like a pretty surefire way to ensure it's not used by Wikimedians at all.

Tbayer reopened this task as Open.Jul 21 2018, 7:06 PM

duplicate of T32574 - there is a patch which implements password lenght attached to T32574. this does not display yet a password meter.

I'm not sure how this is a duplicate of T32574: Display a password strength bar...

Indeed, it seems this was closed based on an erroneous assumption.

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

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

The author has only granted permission for it to be used by Wikimedians/the Wikimedia Foundation, so please don't share the link publicly.

Sounds like a pretty surefire way to ensure it's not used by Wikimedians at all.

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

The author has only granted permission for it to be used by Wikimedians/the Wikimedia Foundation, so please don't share the link publicly.

Sounds like a pretty surefire way to ensure it's not used by Wikimedians at all.

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 author has only granted permission for it to be used by Wikimedians/the Wikimedia Foundation, so please don't share the link publicly.

Sounds like a pretty surefire way to ensure it's not used by Wikimedians at all.

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)

ThurnerRupert closed this task as Invalid.Jul 22 2018, 5:21 AM

duplicate of T32574 - there is a patch which implements password lenght attached to T32574. this does not display yet a password meter.

I'm not sure how this is a duplicate of T32574: Display a password strength bar..

Indeed, it seems this was closed based on an erroneous assumption.

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:

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.

Tgr added a subscriber: Tgr.Jul 24 2018, 8:59 AM

So does the paper actually say anything new?

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:

Tgr added a comment.Jul 24 2018, 9:02 AM

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.

Tgr added a comment.Jul 24 2018, 9:29 AM

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.