Talk:Wikimedia Security Team/Password strengthening 2019

See More

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

More potential privileged groups

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 Krenair ^{(talk • contribs)} 16:02, 29 November 2018 (UTC)

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

Ymblanter (talk) 19:43, 6 December 2018 (UTC)

I posted (what I guess is) the full list into the other section. Researchers and Pathoschild seem to be the two missing things. Tgr (talk) 22:36, 6 December 2018 (UTC)

Well, its a good step, and I think we don't have any issue at Sindhi Wikipedia by implementing it. JogiAsad (talk) 22:37, 6 December 2018 (UTC)

@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) Krenair ^{(talk • contribs)} 22:54, 6 December 2018 (UTC)

Thanks for the suggestions. I've updated the list to be more clear on which accounts are included. CKoerner (WMF) (talk) 15:57, 7 December 2018 (UTC)

So we're still missing:

• Pathoschild's/global deleter
• Researchers Krenair ^{(talk • contribs)} 16:03, 7 December 2018 (UTC)

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. Salvidrim! (talk) 21:52, 12 December 2018 (UTC)

Interface administrators are on there @Salvidrim! Krenair ^{(talk • contribs)} 22:17, 12 December 2018 (UTC)

Edit filter managers, too. They are not that dangerous actually, but can see some private data. Tgr (talk) 01:56, 13 December 2018 (UTC)

More groups?

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

Global Sysops? (Who are also interface admins) Xaosflux (talk) 21:41, 6 December 2018 (UTC)

I think they will get caught automatically by the "has editsitejs" check, but yes, good point. Jdforrester (WMF) (talk) 22:01, 6 December 2018 (UTC)

I imagine this will use wfGetPrivilegedGroups which includes a bunch of other things. The full list is bureaucrats, checkusers, interface editors, sysops (ie. regular admins), oversighters, interface admins, botadmins, eliminators, engineers, templateeditors, a bunch of global groups (abuse filter helpers, founder (Jimmy), global interface editors, global sysops, new wiki importers, ombudsmen, staff, stewards, sysadmins), edit filter managers on enwiki, a bunch of groups on metawiki (centralnotice admins, global renamers, WMF Office IT, WMF Support and Safety), wikidata-staff, plus all users on private and fishbowl wikis. Tgr (talk) 22:31, 6 December 2018 (UTC)

The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

2FA

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

There has also been comments and posts about 2FA requirements which I'm having a hard time getting anyone to reply to (see https://meta.wikimedia.org/wiki/Meta_talk:Interface_administrators) Xaosflux (talk) 21:42, 6 December 2018 (UTC)

I've replied, sorry for the delay and confusion. Now added to m:Interface administrators as well. Jdforrester (WMF) (talk) 21:54, 6 December 2018 (UTC)

The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

Complexity vs. length

People care about complexity because complex passwords are hard to remember. Computers care about length because long passwords are hard to crack. Thank you that you picked strengthening in length department instead of complexity one like lots of other projects. Correct horse battery staple FTW. Utar (talk) 22:10, 6 December 2018 (UTC)

Timeframe

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. Tgr (talk) 22:26, 6 December 2018 (UTC)

Leaving a note so folks don't think we're ignoring Tgr. :) Replies have been made on that task. CKoerner (WMF) (talk) 18:51, 7 December 2018 (UTC)

7-9 character passwords with 2FA - have to lenghten to 10 characters?

@JD accidentally wrote the following in an unrelated thread, I am making it into it's own thread to keep things tidy:

> I got 2FA activated since it has been made available. I don't want to change my general (and pretty complicated) password pattern only because it incorporates 7/8/9 characters instead of 10. There's no need of pushing people into greater password lengths when they're using 2FA already. Krenair ^{(talk • contribs)} 22:31, 6 December 2018 (UTC)

Well, its a good step, and I think we don't have any issue at Sindhi Wikipedia by implementing it. JogiAsad (talk) 22:37, 6 December 2018 (UTC)

Password requirements

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

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. Johnuniq (talk) 22:42, 6 December 2018 (UTC)

I imagine 1234567890 appears in the 100,000-password blacklist. BMacZero (talk) 23:53, 6 December 2018 (UTC)

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. Johnuniq (talk) 02:51, 7 December 2018 (UTC)

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? CKoerner (WMF) (talk) 16:19, 7 December 2018 (UTC)

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. Johnuniq (talk) 01:13, 8 December 2018 (UTC)

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. Misibacsi (talk) 15:00, 7 December 2018 (UTC)

The NIST guidelines (last updated in 2017) actually recommend 8 or more characters. Tgr (talk) 08:15, 9 December 2018 (UTC)

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. ToBeFree (talk) 18:55, 9 December 2018 (UTC)

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. Multichill (talk) 22:00, 9 December 2018 (UTC)

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). Tgr (talk) 22:15, 9 December 2018 (UTC)

One would be very naive to enter one's password there....  Klaas `Z4␟` V:  08:58, 8 December 2018 (UTC)

The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

Warn, not require? Remember previous RfC??

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. Gryllida 23:15, 6 December 2018 (UTC)

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. Manorainjan 18:34, 9 November 2019 (UTC)

Extra user rights and definition of "character"

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. Nyttend (talk) 23:44, 6 December 2018 (UTC)

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. TBolliger (WMF) (talk) 00:50, 7 December 2018 (UTC)

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. Bawolff (talk) 21:54, 9 December 2018 (UTC)

If the current code counts bytes, then you should document that some gap exists between the policy and its actual software enforcement. Incnis Mrsi (talk) 08:07, 15 December 2018 (UTC)

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. Tgr (talk) 08:36, 10 December 2018 (UTC)

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 Bawolff (talk) 10:04, 10 December 2018 (UTC)

What happens if they skip? Do they then get the enhanced permissions but evade the improved password requirements? Mukkakukaku (talk) 02:34, 7 December 2018 (UTC)

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. TBolliger (WMF) (talk) 16:52, 7 December 2018 (UTC)

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? Mukkakukaku (talk) 07:40, 8 December 2018 (UTC)

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. TBolliger (WMF) (talk) 22:47, 10 December 2018 (UTC)

Will using its username as a password be allowed?

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

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, NoFWDaddress (talk) 13:27, 7 December 2018 (UTC)

That requirement remains and is detailed in the policy. This project covers the new additions. CKoerner (WMF) (talk) 16:10, 7 December 2018 (UTC)

The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

Forced update?

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? Ivanvector (talk) 17:22, 7 December 2018 (UTC)

Hello Ivanvector, thanks for your questions.

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. TBolliger (WMF) (talk) 19:35, 7 December 2018 (UTC)

Is the top-100K password list really universal?

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 NickK (talk) 17:44, 8 December 2018 (UTC)

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) (talk) 15:49, 10 December 2018 (UTC)

@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. NickK (talk) 00:35, 12 December 2018 (UTC)

Based on NIST

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

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. Multichill (talk) 13:03, 9 December 2018 (UTC)

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

https://pages.nist.gov/800-63-3/sp800-63b.html CKoerner (WMF) (talk) 14:59, 10 December 2018 (UTC)

The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

Beyond the scope of the NIST paper!

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? ;-) Manorainjan 18:42, 9 November 2019 (UTC)