Thanks for filing this. Triaging.

Waiting for docs access, we'll likely start adding comments there. TY

In T205931#4645463, @Elitre wrote:

Waiting for docs access, we'll likely start adding comments there. TY

Does Sidney already have access to those docs? Thanks.

Everyone with an @wikimedia.org email address should have edit access to that doc now.

Appreciate your patience, Trevor.
You mention a blog post - is that already in the works/shareable? (I looked at the Wikimedia blog and didn't find it there, so assuming it's not published yet)

Thank you for the update, @Elitre! I was just going to ping this, as I've received an email nudge from @JBennett about this project. He will know the target publication date for the blog post, but I think we can move forward with preliminary staff discussions to decide what needs to be brought on wiki and how to present it.

Would it be possible to explore alternative authentication mechanisms instead of using a password?

For instance, perhaps it would be better (as far as security is concerned) to authenticate users on something they have (email, phone number, one time password, etc.) rather than something they know (password)?

This is probably a question for Security rather than us. :)

The proposed changes to the minimum password requirements (or a near-variation of) are live on production for all Wikimedia wikis.

Sadly, this isn't public :(

There are some notes in that document with the Security team that I'm not sure should be public, but here are the requested product changes:

• Increase minimum password length for all newly created accounts from 1 to 8.
• Increase minimum password length for all admin accounts from 8 to 10.
• All newly created accounts and admin accounts must have a password outside the top 100,000 popular passwords. (Current is 100.)
• When a person creates a new account and their password does not match these requirements, the API or the UI should return an appropriate error message.
• When an admin logs in with a password that does not match the requirements, they should see a notification that their password does not match the requirements. (This notification already exists.)
• No change for existing non-admin accounts.

Is there a reason to for increasing the pwlength for new accounts only to 8 ?

Otherwise, I would directly bump to 10 the minimum length both for new users and all admin accounts (I would use even a larger minimum for admins, and we may not want to set a large minimum for everybody, but I see little reason for differentiating between 8 and 10).

I would also add a check for the HIBP Pwned Passwords blacklist.

In T205931#4698821, @Platonides wrote:

Is there a reason to for increasing the pwlength for new accounts only to 8 ?

This is a good question. It's been several months since we discussed these minimums, but if memory serves me correctly there is some research/literature (even on Wikipedia) that shows that 8-characters is a good balance of memorable and secure.

Would love to see some papers on that area.
The links on that section are 10 years old ☹

Looking at the University of Maryland page (which is 21 years old!), and the mention of eight character passwords, they talk a limit of 8-character in the passwords, which is clearly because of the old DES-based crypt(3):

Currently, the maximum password length on many Unix systems is eight characters, but if you want to add a few more characters to make it easier to remember, go ahead. Just bear in mind that anything after the eighth character will be ignored.

Not something that we should worry about. Even the earliest MediaWiki version supported arbitrary-length passwords.☺

Our Security department decided to go with the National Institute of Standards and Technology's latest recommendations, published in June 2017: https://www.nist.gov/publications/digital-identity-guidelines-authentication-and-lifecycle-management

The minimum length is suggested on Page 13 and their rationale is on Page 67.

Nice.

Thanks, TBollinger

(note: they are pages 13 and 67 are according to the internal document numbering, add 10 pages for the absolute page in the pdf)

Interestingly, SP 800-63b mostly argues that user-chosen entropy is hard to predict and defers to the fact that SP 800-63-2 required user-chosen memorized secrets to be a minimum of 8 characters long. It features a more complex entropy estimation (table A.1) based on Shannon experiments, and the 8 characters limit seem to be the Token reuirement for Level 2 access (Table 6).

I met with @TBolliger and have a meeting to discuss CommRel's support with @JBennett on 7 November. We'll be discussing the first two items in the task description.

• Create or help Product Manager create & maintain a project page
• Determine breadth of this consultation and how to best present this work to our users

I'll update the task after the meeting with our proposed plan.

@JBennett and I met today. Here's our suggested communication plan.

• Create subpage for the project
  • Under Wikimedia Security Team on mediawiki.org (Chris to do this)
• Write blog post (John to do this)
• Write announcement (Chris to do this)
  • Keep it short and simple, point to project page for full details, and give a place for folks to raise issues with how password change may impact work
    • Ask for translations
  • When ready, send to Village Pumps via MassMessage
    • Send also to wikimedia-l, wikitech-l, wikitech-ambassadors
    • Include Teahouse and other places new folks hang out (because people will have questions and the communities there can help answer)
    • Include in Tech News

I'll share a draft of the announcement in the next few weeks (eventually a subpage under my username as I do for most announcements). I'll also have a draft of the project page up in the same time frame.

I'll update this task once those are ready.

Sounds great, Chris!

I'll go through the Google Doc today and address/resolve the comments.

Project page is now on-wiki: https://www.mediawiki.org/wiki/Wikimedia_Security_Team/Password_strengthening_2019

Next up the announcement on-wiki.
Really rough draft: https://meta.wikimedia.org/wiki/User:CKoerner_(WMF)/New_password_policy_2019

Policy posted on Meta: https://meta.wikimedia.org/wiki/Password_policy

Draft sent to translators for translation assistance.

https://lists.wikimedia.org/pipermail/translators-l/2018-December/004696.html

I will publish this Thursday.

Targets:

Mailing lists: Wikimedia-l, wikitech-l, Wikitech-ambassadors, cloud-l

On wiki: Village Pumps, Admins (Administrators' newsletter), Tech News

(To be joined by a blog post on wmf.org)

Sent to mailing lists.

• https://lists.wikimedia.org/pipermail/wikimedia-l/2018-December/091440.html
• https://lists.wikimedia.org/pipermail/wikitech-l/2018-December/091200.html
• https://lists.wikimedia.org/pipermail/cloud/2018-December/000465.html
• https://lists.wikimedia.org/pipermail/wikitech-ambassadors/2018-December/002020.html

Added to tech news for this coming Monday: https://meta.wikimedia.org/wiki/Tech/News/2018/50

Sent to Village Pumps as listed here (630 total): https://meta.wikimedia.org/wiki/Distribution_list/Global_message_delivery

Sent to Administrator notice boards (112 total): https://www.wikidata.org/wiki/Q4580256

Wonderful, thank you Chris!

Upon recommendation I have additional sent a message to the stewards-l mailing list (waiting approval) and the Bureaucrats noticeboards.

• https://lists.wikimedia.org/mailman/listinfo/stewards-l
• https://www.wikidata.org/wiki/Q6447242

👍

Thank you Chris! Great work on helping us make and communicate the change. 🚀 🙌🏼 🐙

T208246 was the most significant user-facing change for existing users, and T211622 will release in January and I do not think needs and additional communication other than Tech News, by which we'll just use the User-notice Phabricator tag.