| • csteipp | |
| Oct 20 2015, 4:10 PM |
| F3204978: T116030.patch | |
| Jan 6 2016, 12:13 AM |
From https://lists.wikimedia.org/mailman/private/mediawiki-security/2015-October/000035.html
Set,
'algo' => 'sha512', 'cost' => '128000', 'length' => '64',
For the pbkdf2 parameters at the WMF. This will reduce the amount of work mediawiki does for password hashing by 40%, while increasing the amount of work an attacker has to do by 2.5x.
For our tarball, we should probably adjust the default params to,
'algo' => 'sha512', 'cost' => '40000', 'length' => '64',
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Resolved | Bawolff | T122164 Better limitation on number of password guesses people can make | |||
| Restricted Task | |||||
| Duplicate | None | T122123 Send echo notification to user of how many failed logins there was since last successful login | |||
| Open | None | T122248 Password/login related security issues (Tracking) | |||
| Restricted Task | |||||
| Restricted Task | |||||
| Resolved | • demon | T124940 MediaWiki 1.26.3 security release | |||
| Resolved | • csteipp | T116030 Increase pbkdf2 parameter strengths (2015/2016) | |||
| Resolved | None | T127396 Logins with CentralAuth fail when password re-hashed |
Don't add Security-Team here, otherwise all member of a public joinable project can see this task! This is not willed, I guess.
@Luke081515: Nope that's not how the access permissions in Phabricator are implemented. :) Readded.
@Aklapper: Normaly, but this projects was not added as project:
Luke081515 removed a subscriber: Security-Team.
This projects was added as CC, and this was why I can see the task before: Normaly I'm not a member in Security, and should only see the security bugs I created, but I added me as a member of Security-Team, and so I could see the task.
Interesting. I wrote and am running a script to track down other instances of that across tickets marked security, and have fixed T101341 and T115333 so far.
Also T100803 in WMF-NDA. Going to remove the project restriction soon and let it check everything I can see in Phab.
Edit: After it gets to something like offset 42k, my script starts getting "Maximum execution time of 10 seconds exceeded" HTTP 500s unfortunately. Still:
Not pasting the output here due to the obvious issues involving what my account can access.
Since this is really a hardening issue (someone would have to get our password hashes to crack them), and since the original 64k strength still holds (the WMF is just doing 4x that when checking passwords), I'm going to push this as a public patch to be swatted tomorrow (28 Jan).
This was deployed with https://gerrit.wikimedia.org/r/#/c/274795/.
This has been live on all wikis for about 2 hours, and 4k hashes have been converted so far. Authentications (https://grafana.wikimedia.org/dashboard/db/authentications) seem to be progressing at the normal pace.
Stats from CountPasswordTypes2.php
md5:12034721
type-a:84656
type-b:24063500
pbkdf2 (256):9552526
pbkdf2 (512):4485
zero-length:103908
'nologin':257
Public patch for DefaultSettings.php is https://gerrit.wikimedia.org/r/275868 (since T127445 was opened publicly).
I think we can just cherry pick that back to all the release branches, unless that throws off creating the security patch?