Implement results of enwiki Security review RfC
Open, LowPublic

Description

https://en.wikipedia.org/wiki/Wikipedia:Security_review_RfC

Results:

  • Length increase to 6 bytes
  • Length increase to 8 bytes
  • Uncommon passwords
  • Add a password strength bar to the "Create account" page
  • Password requirements for Crats, Stewards and Founder groups
  • Password requirements for Functionary group
  • Password requirements for Administrator group
  • Password requirements for Edit Filter Manager group
  • Regular audits for Functionary group
  • Regular audits for Administrator group

Of these

  • Increasing the password length is to 8 bytes and requiring uncommon passwords are easy: T119100: Increase MinimalPasswordLength to 8 for several local and global groups
    • Since policies are group based, we'll apply the settings to the local enwiki groups: sysops, bureaucrat, steward, and founder
  • Adding a password strength meter is a good idea, but will require some development work
  • Regular audits will take some work to get setup
csteipp created this task.Dec 11 2015, 2:05 AM
csteipp updated the task description. (Show Details)
csteipp raised the priority of this task from to Needs Triage.
csteipp added a subscriber: csteipp.
Restricted Application added subscribers: StudiesWorld, Aklapper. · View Herald TranscriptDec 11 2015, 2:05 AM
Restricted Application added subscribers: JEumerus, Matanya. · View Herald TranscriptJan 22 2016, 11:30 AM
csteipp moved this task from Backlog to In Progress on the Security-Team board.Jan 26 2016, 4:48 PM
csteipp claimed this task.Feb 26 2016, 8:17 PM
csteipp updated the task description. (Show Details)Mar 15 2016, 3:26 PM
Reedy added a subscriber: Reedy.Oct 31 2016, 9:46 PM

Password requirements for Edit Filter Manager group

Which group is this? Abuse filter editors on enwiki?

Change 319000 had a related patch set uploaded (by Reedy):
Increase password requirements on enwiki for "Abuse filter editors"

https://gerrit.wikimedia.org/r/319000

Change 319000 merged by jenkins-bot:
Increase password requirements on enwiki for "Abuse filter editors"

https://gerrit.wikimedia.org/r/319000

Reedy updated the task description. (Show Details)Nov 4 2016, 3:25 PM
Reedy triaged this task as Low priority.Nov 4 2016, 3:58 PM
Aklapper removed csteipp as the assignee of this task.
Bawolff added a subscriber: Bawolff.Dec 9 2017, 1:59 PM

Regular audits will take some work to get setup

I don't think anyone ever decided what is meant by this (running hashcat against functionary password hashes? Ensuring they have 2FA? Something else)

Samtar added a subscriber: Samtar.Dec 27 2017, 2:58 PM

Regular audits will take some work to get setup

I don't think anyone ever decided what is meant by this (running hashcat against functionary password hashes? Ensuring they have 2FA? Something else)

Personally, and mindful of ease vs usefulness, a "regular audit" would be:

  • Run every 6 months (its just a number, but twice a year seems reasonable)
  • Enforcing/checking 2FA is enabled (depending on if 2FA ever became a requirement, which is unlikely - we should at least have statistics)
  • Checking functionary/administrator's passwords against a "top X" list (nb. "commonly used" passwords cannot be chosen)
  • Running hashcat against functionary's passwords (guessing this would be resource expensive, hence limiting to only functionary password hashes)

Thoughts? How much of this could be automated, to whom would the results go, and what would happen if an account "failed" the audit?

DoRD added a subscriber: DoRD.Dec 28 2017, 12:20 PM

Run every 6 months (its just a number, but twice a year seems reasonable)

Sounds reasonable.

Enforcing/checking 2FA is enabled (depending on if 2FA ever became a requirement, which is unlikely - we should at least have statistics)

Yeah, we could definitely generate statistics.

Checking functionary/administrator's passwords against a "top X" list (nb. "commonly used" passwords cannot be chosen)

We already don't let them chose top x passwords. Although if they chose a top x password previously before being promoted, they get asked to change it, but they are able to press "cancel" so I guess we could check if they actually have changed it.

Also I guess there's the case of Admins who have been inactive for like 10 years (on projects without an inactive policy)

Running hashcat against functionary's passwords (guessing this would be resource expensive, hence limiting to only functionary password hashes)

This is something we'd have to look into how do-able it is. Additionally, for best performance it should use the GPU based ocl-hashcat (I assume. I don't know much about ocl-hashcat). I guess we do have a GPU on Stat1005 that could potentially be used.

This is probably the measure that would be most effective - but also the measure that I'm least sure about if we can do.

Great points, thank you @Bawolff - what do you think of also checking passwords against https://haveibeenpwned.com/Passwords ?

Great points, thank you @Bawolff - what do you think of also checking passwords against https://haveibeenpwned.com/Passwords ?

Obviously we're not going to start doing web requests to the website to check each password... So we would need a copy of the data ourselves, and to stick it somewhere...

However, we have https://packagist.org/packages/wikimedia/password-blacklist which uses https://github.com/danielmiessler/SecLists/blob/aad07ff/Passwords/10_million_password_list_top_100000.txt to come at a similar problem from a slightly different angle. So we can blacklist the 100,000 most used passwords

I just need to finish the integration into MW...

See T151425 and it's related tasks

Samtar added a comment.EditedFeb 24 2018, 9:46 AM

Obviously we're not going to start doing web requests to the website to check each password... So we would need a copy of the data ourselves, and to stick it somewhere...

I agree, so I linked to a page which specifically mentioned "Downloading the [list]", but here's a more detailed write up if anyone needs some more info.
I thought we could probably compare through these and notify users who have passwords included in public breach data?

I brought this up because NIST guidelines "recommend that user-provided passwords be checked against existing data breaches". I strongly believe we should be taking this very basic step in protecting our users' account security.

I've already mentioned SecLists above, I'd 100% like to see the number upped to 100,000 - thank you for working on this!

It's great to see some forward movement on this task :)

Reedy added a comment.EditedFeb 24 2018, 10:06 AM

Obviously, which is why I linked to a page which specifically mentioned "Downloading the [list]", but here's a more detailed write up if you're struggling to follow.

Sure, but the first thing on the page is a text box to put passwords in. "Downloading the Pwned Passwords list" is the last thing on the page. Neither is the page titled "Get the Passwords" or "Download the Passwords" etc

Although I also agree we probably should be doing it, or something along those lines, however I wouldn't suggest it's "very basic"... And we're only going to be able to do so at the point of login (because that's the only time we're going to get their password in a format we can just sha1 it to look at it on those list). Probably queuing a job queue job to go off and have a look, reporting back with emails/echo notifications etc. And potentially flagging the user that they need to change their password at next login etc.

As the password lists aren't actually given as clear text (for good reason), we can't easily (or at all? not without massive amounts of bruteforcing somewhere along the lines. Certainly impleneting our salting into something else like hashcat to do it) do regular scans against the user table to find what matches (because of our salting), so again, we're only going to be able to do that at a login/password change type event. Unless we brute forced them back to plain text (no), to then run foreach password salt per user and compare password... Just no.

As for seclists, yes. I was pointing out that some of the implementation for that has already been done.

I was only making a suggestion

Dcljr added a subscriber: Dcljr.EditedFeb 25 2018, 1:56 AM

<offtopic>Umm… I'm supposed to check whether my passwords have been breached by submitting them to this website? I think not! (I downloaded the list and checked them locally, BTW.)</offtopic>

As for addressing @Reedy's concerns, the "more detailed writeup" Samtar linked to mentions that clear-text lists of breached passwords are indeed publicly available online (not at that website, but the "writeup" page links to two of them), so "we" could get some of those lists and process them into a form we can actually use. (This still would not be a trivial task, but presumably it would be easier than the kind of coding Reedy was envisioning.)

Samtar removed a subscriber: Samtar.Mar 6 2018, 12:24 PM