Talk:Wikimedia Security Team/Password strengthening 2019

Feedback on how the password strengthening project might impact your work is welcome.

The initial statement was: "The Wikimedia Security team has chosen to base our requirements on the National Institute of Standards and Technology guidelines."

Now, that very paper states its scope as:

"These guidelines provide technical requirements for federal agencies implementing digital identity services and are not intended to constrain the development or use of standards outside of this purpose."

I guess, the English phrase for this is: "to take a sledgehammer to crack a nut"

How much of a federal agency is Wikimedia? ;-)

I think there was a request for comment previously and the outcome was that enforcing any password strength is bad, instead a warning should be shown. Perhaps Requests for comment/Passwords is a part of that discussion, it may have happened at more than one place however.

A quote from that page is "We can encourage stronger passwords without requiring them."

I think this may be worth implementing, perhaps as

• an e-mail to privileged users whose password is weak, and
• a warning ui for people who are signing up.

In the NIST paper it is mentioned:

A.1 Introduction

Despite widespread frustration with the use of passwords from both a usability and security standpoint, they remain a very widely used form of authentication [Persistence]. Humans, however, have only a limited ability to memorize complex, arbitrary secrets, so they often choose passwords that can be easily guessed. To address the resultant security concerns, online services have introduced rules in an effort to increase the complexity of these memorized secrets. The most notable form of these is composition rules, which require the user to choose passwords constructed using a mix of character types, such as at least one digit, uppercase letter, and symbol. However, analyses of breached password databases reveal that the benefit of such rules is not nearly as significant as initially thought [Policies], although the impact on usability and memorability is severe.

Two concerns:

(1) How will you handle a situation in which a user with an 8- or 9-character password is given advanced rights? We can't risk someone being locked out of an account because a change in user rights makes their current password invalid. I hope the answer is that they'll be prompted to change the password immediately.

(2) What is a character? Is it ASCII characters, or Unicode, or Latin script, or something else? If it's eight or ten graphemes, this may pose problems for Chinese users in particular, given the nature of the language's writing system; that's analogous to requiring anglophones to remember a password of eight or ten words.

Not true: are not words, but syllables. It's not so hard to remember a word of 8 syllables. There are numerous tools to save your passwords and/or -phrases securely so you have to remember only one master.passwd Klaas `Z4␟` V:  08:50, 8 December 2018 (UTC)

Hello Nyttend! Good questions, thank you for asking.

1) This functionality already exists — the current minimum password length for a permissioned account is 8 characters. If an account with a password shorter than 8 character password receives permissions, the next time they log in they will be shown a skippable message that encourages them to change their password:

2) I'm mostly confident that it is unicode characters, but will double check with the developers.

Current code (Unless someone is planning to change it) is checking number of bytes. So a unicode code point can be between 1-4 bytes depending on where in unicode it is found. And actual things that look like a single symbol may be multiple code points.

For example in the current code* implementation, a password consisting of the pride flag emoiji 🏳️‍🌈 would be considered a 14 character password.

*I should stress, I'm just saying what's currently there, I have no idea if the plan is to change it.

If the current code counts bytes, then you should document that some gap exists between the policy and its actual software enforcement.

Filed as T211550. Seems like a nontrivial problem though - accented latin characters probably shouldn't count double, emojis probably shouldn't count as 4 characters (the number of "popular" emojis is probably pretty small), Chinese characters counting as 3-4 might be reasonable.

I think passwords get converted to NFC - so if we were counting code points instead of bytes common (but not all) accented latin characters would probably count as 1.

I also just discovered that grapheme_strlen() is a thing in php

What happens if they skip? Do they then get the enhanced permissions but evade the improved password requirements?

Yes, they can log-in and use all functionality. The next time they log-in they will see the same prompt and can skip it again.

That kind of defeats the purpose of this feature then, doesn't it? If I get promoted, and my password is insufficient, then I can just skip forever and ever and continue using my weak password with enhanced permissions leaving what effectively is a security hole: my account with elevated permissions can be broken into much easier that other administrators'. It's kind of like having a "you must change your password every three months" rule and then letting the user keep their old one anyway if they don't feel like changing it. Should security really be opt-in?

You are correct — this is lax. The Wikimedia Foundation's Security team is aware of this shortcoming and may want to address it in the future with additional changes.

I think stewards are fairly obvious so I've boldly gone and added that to the list. But what about these global groups?

• Abuse filter helpers
• Founders
• Pathoschild's group
• New wiki importers
• Ombudsmen
• System administrators
• WMF researchers

I believe stewards are now required to have TFA, so that there was no point in adding them.

I posted (what I guess is) the full list into the other section. Researchers and Pathoschild seem to be the two missing things.

Well, its a good step, and I think we don't have any issue at Sindhi Wikipedia by implementing it.

@Tgr I think researchers should be added, they have some important permissions:

• View deleted history entries, without their associated text (deletedhistory)
• View deleted text and changes between deleted revisions (deletedtext)
• View private logs (suppressionlog)
• View, hide and unhide specific revisions of pages from any user (suppressrevision)
• Undelete a page (undelete)

Pathoschild's group (seems to also be known as global deleter) has some important ones too:

• Search deleted pages (browsearchive)
• Delete pages (delete)
• View deleted history entries, without their associated text (deletedhistory)
• View deleted text and changes between deleted revisions (deletedtext)
• Undelete a page (undelete)

Thanks for the suggestions. I've updated the list to be more clear on which accounts are included.

So we're still missing:

• Pathoschild's/global deleter
• Researchers

I see "Global interface editors" on the list, but not local Interface Administrators (aka techadmins, see enwiki page). I also think edit filter managers should be considered "privileged". Both permissions give the ability to completely lock down editing on a wiki if in malicious hands.

Interface administrators are on there @Salvidrim!

Edit filter managers, too. They are not that dangerous actually, but can see some private data.

Having looked through the list, it looks very Latin and probably American.

There is no way the most popular Cyrillic passwords like "пароль" would not be there: "пароль" is an equivalent of "password" (2nd place) and even its transliterated variant ("пароль" written in Latin keyboard layout, i.e. "gfhjkm") is there at 111th place. Transliterated versions of another popular passwords like "lhfrjy" ("dragon" - 10th place, translated to "дракон" and transliterated to "lhfrjy" - 9089th place) or "vfcnth" ("master" - 19th place, translated to "мастер" and transliterated to "vfcnth" - 11875th place) are also there.

I would thus bet there should be dozens of Cyrillic passwords (and probably in other alphabets like Arabic or Chinese) in this list. Notably the two most popular (and ridiculous) Cyrillic passwords, "пароль" ("password") and "йцукен" (equivalent of "qwerty", 4th place) should clearly be in top-100. It would be strange to ban "gfhjkm" (a person made at least a minor security effort) and not to ban "пароль" (an immediate guess for a Cyrillic user).

Could you please thus check you picked a really universal list? Thanks

The list of passwords is based upon the Weakpass project's best wordlists. The list is based upon real passwords used by people from various sources across the internet. Given the general bias of the internet to English, it's understandable that most included would be Latin. They do offer other language lists. I'll bring your recommendation up to the security team.

@CKoerner (WMF): I agree that this is a real list of passwords used by real people. I just believe that for some reason this list includes only passwords containing in standard Latin.

This list may make sense for websites having such a constraint for passwords, but WMF wikis accept passwords with any characters. Thus we miss:

• non-Latin alphabets (as mentioned above)
• commas. For instance, the list contains "k.lvbkf" ("людмила" typed in Latin layout, Lyudmila a rather common Cyrillic name), but it does not contain "aen,jk" ("football" translated to "футбол" and typed in Latin layout, while "football" is #14 and is clearly popular in countries where Cyrillic alphabet is used) or ",julfy" ("богдан" typed in Latin layout, Bogdan is a common Cyrillic name and is #3177).
• extended Latin. It is quite surprising to see "jurgen" and "juergen" and not "jürgen" (Jürgen is one of the most common German first names)

... probably something else.

Thus this is not really a language list issue but probably some constraint imposed on this list. I think the best idea is to look for list of most common passwords without any constraints on what password can contain. Not sure dictionaries by language should really be used, the most popular one contains some very uncommon words that can really be reasonably secure passwords (like "Tuschzeichnungen" or "lawyeresses"). From this point of view top-100K is really good as it does contain all things people really use as passwords (first names, names of sports teams, places, birthdays etc.), it just should be extended beyond some constraints.

Please fix the Password requirements section which currently suggests that a privileged account with password "123456" could change it to "1234567890" when they next log in.

I imagine 1234567890 appears in the 100,000-password blacklist.

Yes it is in the list: that is my point. The current text does not say that the full password policy will be enforced when a privileged user next logs in. Similar confused wording applies for non-privileged users.

Ah, apologies for the confusion. The requirements section does state for privileged accounts, "This is enforced the next time the user logs in"

I just made an edit that tries to make it a little more clear. Does that help?

Thanks, but no, that did not help. The problem is the bulleted text in the "Password requirements" section. That clearly states that a minimum length of 10 characters for the password of a privileged account will be enforced at next log in. The top 100,000 requirement is separate and there is no mention of when or whether it will be enforced. I would be happy to fix the wording, which you would obviously check, but I have no idea what the plan is.

Please be aware that an 8-character password is considered as weak. It can be broken within 2 hours (if random enough). Go and try: https://howsecureismypassword.net/

Recommendation nowadays (2018): 12 characters with Upper and lowercase, numbers and special characters.

Please reconsider it and update your requirements.

The NIST guidelines (last updated in 2017) actually recommend 8 or more characters.

8 character Unicode passwords surely can not be broken within hours by any means available on Earth. Also, the attack scenario is not an offline attack, it is subject to rate limits unless someone steals the database.

You're making a classic mistake here. The 8 character password is weak is based on the assumption you can a do a Brute-force attack. In the case of the web service (like Wikipedia), that's not the case. You can't just try, try and try, mechanisms are in place to slow you down. Compare it with a pin code on an ATM card. Generally only 4 digits long, but generally secure enough because after three failed tries, the card stops working.

FWIW even against bruteforcing by an attacker with access to the hash, 8 random characters are not really weak. If you use PBKDF2 with 10K+ rounds as per the NIST recommendation (Wikimedia uses 128K rounds), an attacker on a high-tier PC will be down to a few ten thousand tries per second (so about a month to bruteforce a single all-lowercase random 8 character password, about 100 years if it's mixed case + numbers).

One would be very naive to enter one's password there....

Did you base your new policy on https://pages.nist.gov/800-63-3/sp800-63b.html#memsecret ? I didn't see any reference to it. You might want to check it out and reference it.

There's a reference to the NIST guidelines in the Password requirements section.

https://pages.nist.gov/800-63-3/sp800-63b.html

Neat interface you got here. Couple questions:

1) are all privileged users now required to choose a new password? Or only those who do not meet the new requirements at the time of implementation?

1a) what happens to an account that does not comply?

2) are existing non-privileged accounts subject to the new requirements at implementation, or will they be in the future? Or is this only for new accounts?

Hello Ivanvector, thanks for your questions.

error message when a privileged user logs in with a short password

1) No. Those who have passwords that meet the new requirements can carry-on with business as usual. Those who do not meet the new requirements will see the warning message (pictured right) when they log in. When they change or reset their password the new password minimums will be required.

We strongly encourage privileged users to not skip this step and to update the passwords.

2) At this time all existing non-privileged accounts will not need to change their passwords unless they manually change or reset their passwords.

It is important to note that password requirements will never be set in stone — there may be other changes in the future. Password security is an ever-evolving and ever-maturing topic and we want to make sure all our users and our wikis are safe from malicious actors.

I don't think the one-week timeframe that was announced on the mailing list is wise. I left a more detailed comment at T208246#4804686.

Leaving a note so folks don't think we're ignoring Tgr. :) Replies have been made on that task.

No.

Hello,

I might not have read properly, but it appears that the old criteria disallowing a user to set his username as password won't be kept. Is it the case?

Best,

That requirement remains and is detailed in the policy. This project covers the new additions.