Password requirements for Edit Filter Manager group

Which group is this? Abuse filter editors on enwiki?

Yes.

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

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)

In T121186#3825194, @Bawolff wrote:

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?

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 ?

In T121186#3997804, @Samtar wrote:

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

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

In T121186#3998652, @Samtar wrote:

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

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