Page MenuHomePhabricator

Password blacklist not consistently enforced
Open, NormalPublic

Description

According to enwiki:WP:STRONGPASS (which is the only published info I could find about what Wikimedia's password policies are), the only requirements for passwords are that they be at least 8 bytes and not match the OWASP top 10,000 most common passwords list. In addition, these rules are only supposed to apply to people with super dangerous privileges -- there are supposed to be no requirements for normal users.

I don't have a super powerful account to test those rules on, but I notice this doesn't seem to be consistent with what actually happens for unprivileged users. Unprivileged users are blocked from using some common passwords, but not all of them from that list. In fact, the 7th most popular password "1234" is permitted. Here's the results of me testing the first few dozen passwords on the OWASP list:

123456blocked
passwordblocked
12345678blocked
qwertyblocked
123456789blocked
12345blocked
1234ALLOWED
111111blocked
1234567blocked
dragonblocked
123123blocked
baseballALLOWED
abc123blocked
footballblocked
monkeyblocked
letmeinALLOWED
696969ALLOWED
shadowblocked
masterALLOWED
666666blocked
qwertyuiopALLOWED
123321ALLOWED
mustangALLOWED
1234567890blocked
michaelblocked
654321blocked
pussyALLOWED
supermanblocked
1qaz2wsxALLOWED
7777777ALLOWED
fuckyoublocked

It doesn't seem to make any sense to me to ban some really common passwords, but not others, so I just wanted to clarify whether or not this is intentional behavior. Obviously I don't know what $wgPasswordPolicy is set to, so I can't tell.

Since I at least know that PasswordCannotBePopular must be enabled (although I don't know what $wgPopularPasswordFile is set to), I could assume that the hardcoded passwords in that function must be banned. And indeed, "" (empty string), "wiki", "mediawiki" and $sitename do appear to be banned. However, because Wikimedia passwords are synced across multiple sites, the $sitename restriction causes weird behavior. I can't set my password to "wikipedia" on Wikipedia, but I can login to, say, Wikivoyage and set it to "wikipedia" there. When I log back into Wikipedia, it'll ask me to change my password, but it won't force me to (I can just leave the page).

Event Timeline

IagoQnsi created this task.Aug 24 2017, 6:46 PM
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptAug 24 2017, 6:46 PM

Thanks for reporting this!

Here's the results of me testing the first few dozen passwords on the OWASP list:

How did you test and where exactly? Some Wikimedia site? Which one? Or your own MediaWiki installation? Which version and settings?
Please see https://mediawiki.org/wiki/How_to_report_a_bug - thanks! :)

Samtar added a subscriber: Samtar.Aug 25 2017, 7:22 AM

@IagoQnsi if you are referring to Wikimedia wikis (which I'm going to guess you are per However, because Wikimedia passwords are synced across multiple sites), the password policies are defined in CommonSettings.php

$wgPopularPasswordFile is generated using maintenance/createCommonPasswordCdb.php

Aklapper changed the task status from Open to Stalled.Aug 30 2017, 7:39 AM
IagoQnsi added a comment.EditedSep 1 2017, 5:14 PM

Yes, this was on Wikimedia sites. I tested that list of passwords against en.wikipedia, but brief testing indicated that the list was the same on other Wikimedia wikis.

Thank you for those links, I didn't realize Wikimedia's settings files were public. I can't tell what is being used as the input file for createCommonPasswordCdb.php, but I'm guessing it's just a different version of the OWASP list. In CommonSettings.php line 407, it looks like the top 100 passwords from the list are banned for non-privileged passwords (as opposed to no common passwords being banned whatsoever). It must just be that the passwords that were allowed in my testing above weren't in the top 100 on whatever version of the OWASP list being used on Wikimedia.

I guess my suggestions at this point are:

  1. Make sure the version of the OWASP list currently in use is a up-to-date/correct copy of the list. I can't figure out where Wikimedia's copy of this list is stored, but it's weird that obvious passwords like "1234" and "baseball" are apparently not in the top 100.
  2. Add all Wikimedia site names to the popular password list on all Wikimedia sites (and make sure those passwords are in the top 100). It's unlikely someone would deliberately do this, but it is very weird imho that you can make your password "wikipedia" or "wiktionary" by setting it on a different Wikimedia wiki. The ban list should probably be: wikipedia, wiktionary, wikiquote, wikibooks, wikisource, wikinews, wikiversity, wikispecies, wikidata, commons, wikivoyage.
  3. enwiki:WP:STRONGPASS should be corrected to show the real rules for unprivileged users. I will take care of this -- however, I would appreciate if someone could point me to the copy of the OWASP list that Wikimedia is using, so I can update "enwiki:WP:Most common passwords/10000".
Reedy added a subscriber: Reedy.

https://github.com/wikimedia/mediawiki/blob/master/serialized/commonpasswords.cdb

From commit https://github.com/wikimedia/mediawiki/commit/2d15dcfc3f4bf81552b378ce5003661c1681b38c

Which doesn't say it's from the OWASP common password list, it's from a link that's now dead (I can try and dig up a working link again)

https://en.wikipedia.org/wiki/Wikipedia:Most_common_passwords/10000 was not written by a MediaWiki developer, nor the implementor of that feature and the inclusion of the initial list. It is completely seperate

Password Policies as set on WMF wikis can be seen on https://noc.wikimedia.org/conf/highlight.php?file=CommonSettings.php

Reedy added a comment.Sep 1 2017, 5:37 PM

As an aside, I just filed T174812: Add a Special:PasswordPolicies page to make some sort of special page so we can see visibly how the policies are being applied to user groups. User parsing of $wgPasswordPolicy isn't a great idea :)

Reedy added a comment.Sep 1 2017, 5:43 PM

Which doesn't say it's from the OWASP common password list, it's from a link that's now dead (I can try and dig up a working link again)

Looking further at https://github.com/danielmiessler/SecLists it seems it's some sort of OWASP project...

Anyway, we're not using the "top password list" it's from the rockyou lists - https://gerrit.wikimedia.org/r/#/c/254754/

Many many choices on https://github.com/danielmiessler/SecLists/tree/master/Passwords for sure

Reedy added a comment.EditedSep 1 2017, 5:44 PM

Since I at least know that PasswordCannotBePopular must be enabled (although I don't know what $wgPopularPasswordFile is set to), I could assume that the hardcoded passwords in that function must be banned. And indeed, "" (empty string), "wiki", "mediawiki" and $sitename do appear to be banned. However, because Wikimedia passwords are synced across multiple sites, the $sitename restriction causes weird behavior. I can't set my password to "wikipedia" on Wikipedia, but I can login to, say, Wikivoyage and set it to "wikipedia" there. When I log back into Wikipedia, it'll ask me to change my password, but it won't force me to (I can just leave the page).

T151425#2816835

And also T118774: No way to force a user to change their password if it's invalid

https://github.com/wikimedia/mediawiki/blob/master/includes/password/PasswordPolicyChecks.php#L143

So that is done to some extent... So should ban wikipedia on wikipedia..

			$hardcodedCommonPasswords = [ '', 'wiki', 'mediawiki', $sitename ];
			if ( in_array( $passwordKey, $hardcodedCommonPasswords ) ) {
				$status->error( 'passwordtoopopular' );
				return $status;
			}
dpatrick changed the task status from Stalled to Open.Sep 6 2017, 4:25 PM
dpatrick assigned this task to Reedy.
dpatrick triaged this task as Normal priority.
Keer25 added a subscriber: Keer25.Jan 4 2018, 7:51 PM