Mostly exploratory/discovery work at this point but as part of discovery we are looking at what it might take to decouple authentication from MediaWIki.

Approved

Approved

approved

Approved.

I'm not aware of prior management decisions or risk assessments to prohibit no-transform and I'm only seeing an upside to making this change. Seems like the evidence we have suggests performance issues are negligible, increased analytics in areas where we are seeking growth and we have improved security and privacy by not proxying and this feels like a relatively easy fix. I'm supportive of making this change happy to discuss other options but in the interest of mitigating immediate concerns and risks this seems like a good fit so can we go ahead and add no-transform?

More documentation

In T289899#7403249, @Legoktm wrote:

I'd still like to get this reviewed somehow, given how much private information is passing through it.

Approved from my end.

The Security team is updating their readiness review SOP to reflect a new change that any request that has aged 90 days without being in a reviewable state will be declined. We do this to help keep our work area current, accurate and reflective of actual work. If the status of your project changes please re-tag us and we will get this work scheduled.

The Security team is updating their readiness review SOP to reflect a new change that any request that has aged 90 days without being in a reviewable state will be declined. We do this to help keep our work area current, accurate and reflective of actual work. If the status of your project changes please re-tag us and we will get this work scheduled.

The Security team is updating their readiness review SOP to reflect a new change that any request that has aged 90 days without being in a reviewable state will be declined. We do this to help keep our work area current, accurate and reflective of actual work. If the status of your project changes please re-tag us and we will get this work scheduled.

The Security team is updating their readiness review SOP to reflect a new change that any request that has aged 90 days without being in a reviewable state will be declined. We do this to help keep our work area current, accurate and reflective of actual work. If the status of your project changes please re-tag us and we will get this work scheduled.

I'm going to chime in here:

Nothing we need to keep, good to cleanup, thanks!

approved

Looks good, thanks!

Approved

approved

How is the patch coming along? When do we expect this to be deployed?

Sure, charter is at https://www.mediawiki.org/wiki/Wikimedia_Security_Team/Council

Approved

@Eevans @Clarakosi This one is a bit out of our wheelhouse and something we can provide only a cursory review of. I'd like to propose the following: The Security team can perform a basic security review of this but I would recommend a secondary review by our 3rd party partners at BishopFox. That said, the 2nd review would incur some cost but I'm not sure how much. Do you have any budget available for something like that??

Todays updates sent to wikitech-l https://lists.wikimedia.org/pipermail/wikitech-l/2019-March/091769.html

Approved

In T210667#4812704, @Legoktm wrote:

In T210667#4795435, @JBennett wrote:

Thanks everyone of for their thoughtful consideration. I have no issues nor do I see a conflict with temporarily allowing the use of this so we can complete our work with our 3rd party partners.

Thanks for commenting. To clarify, are you saying that there is no free filesystem software that will meet our needs? Given that @Platonides offered a decent amount of alternatives in T210667#4789273, it would be helpful if it could be explained why none of those alternatives are sufficient. That will help me when I reach out to various free software upstreams so they can improve their software so it will meet our needs - a goal that I think we all share.

In T151011#4808817, @Tgr wrote:

There are two types of good password generation:

1. A medium-length string of random uppercase/lowercase/numbers (say 12 or 16 characters), with easily confusable characters removed from the pool.
2. A long human-readable text of space-separated random dictionary words (probably 5 or 6 words), e.g. diceware.

I'm not sure the first is worth doing as the only sane way to use such passwords is a password manager and that can generate random passwords just fine. (Maybe there are less technical users who have problems with password managers and just write the passwords down, but those are better served by diceware style passwords anyway since words are easier to type.) OTOH it is very trivial to implement.

The second is good for people who need to memorize the password for some reason, or need to type it in often (ie. often log in on foreign machines). The best library I have seen for it is grempe/diceware (test page), which has support for ~20 languages (of course it would be fairly trivial to add more). Word lists are around 100K which is a bit large but they don't exactly make an effort to reduce the size, which could be done pretty easily.

In T208246#4804686, @Tgr wrote:

This feels a bit rushed. Maybe I am just not aware that the preparations already happened, in which case apologies in advance, but otherwise I would recommend pushing out the date by a month or so and doing more groundwork.

In T151425#4796448, @Reedy wrote:

In T151425#4795744, @TBolliger wrote:

I'm fairly confident the plan is for all new passwords to be outside 100,000. This is based on this permissioned Google Doc authored by @JBennett. It was last edited Nov. 1 so other decisions/discussions may supercede this.

Ping @JBennett! 🛎

Well, WMF != MW. But if the intention is to make these changes for all users and help "harden" MW core at the same time, I'm fine with making that change in MW core too

2. With respect to the WMF charter and the values and manifestation thereof, it seems the exception process and/or the bar for each use case is at the discretion of WMF leadership and probably specifically most informed by WMF technical leadership. I'll defer to @JBennett who has more information.

In T189641#4789805, @Tgr wrote:

In T189641#4789786, @chasemp wrote:

Adding @JBennett as I see he raised concern with the ihaveibeenpwned work in related https://phabricator.wikimedia.org/T210192#4786955

I think that was meant for using it for email lookup, not passwords? If your password hash is in the dump, the applicability of that is pretty clear.

In T208441#4711167, @TBolliger wrote:

In T208441#4710847, @Framawiki wrote:

Related: T197577: Increase password policies for the 'steward' group and others

Yeah, good catch. Makes sense to bump this one up too. I forget, though... do Stewarts also need 2FA? If so, the length is less of an issue.

I'm in favor of removing unblock self. It's overly permissive to allow admins to unlock themselves and we should follow some level of separation of duties to ensure proper governance. Let's go ahead and make this change.

+1 from me

I'm not 100% sure who should be claiming this task. Could one of you please claim it in support of this recent security incident?

Our process around security incident response is evolving and something the security team is working to improve. We're not there yet but we are definatley making improvements.

This 1st round is really to address changes to our wiki password policy. Phase 2 is being planned and will address 2FA for privileged users.

In progress