Talk:Wikimedia Security Team/Password strengthening 2019

Jump to navigation Jump to search

About this board

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

Extra user rights and definition of "character"

10
Nyttend (talkcontribs)

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.

KlaasZ4usV (talkcontribs)

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)

TBolliger (WMF) (talkcontribs)

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.

Bawolff (talkcontribs)

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.

Tgr (talkcontribs)

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.

Bawolff (talkcontribs)

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

Mukkakukaku (talkcontribs)

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

TBolliger (WMF) (talkcontribs)

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.

Mukkakukaku (talkcontribs)

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?

TBolliger (WMF) (talkcontribs)

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.

Reply to "Extra user rights and definition of "character""
Johnuniq (talkcontribs)

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.

BMacZero (talkcontribs)

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

Johnuniq (talkcontribs)

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.

CKoerner (WMF) (talkcontribs)

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?

Johnuniq (talkcontribs)

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.

Misibacsi (talkcontribs)
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.
Tgr (talkcontribs)

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

ToBeFree (talkcontribs)

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.

Multichill (talkcontribs)

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.

Tgr (talkcontribs)

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).

KlaasZ4usV (talkcontribs)

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

Multichill (talkcontribs)
CKoerner (WMF) (talkcontribs)

Is the top-100K password list really universal?

2
NickK (talkcontribs)

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

CKoerner (WMF) (talkcontribs)

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.

Reply to "Is the top-100K password list really universal?"
Ivanvector (talkcontribs)

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?

TBolliger (WMF) (talkcontribs)

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.

Reply to "Forced update?"
Tgr (talkcontribs)

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.

CKoerner (WMF) (talkcontribs)

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

Reply to "Timeframe"

Will using its username as a password be allowed?

2
Summary by Jdforrester (WMF)

No.

AntonierCH (talkcontribs)

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,

CKoerner (WMF) (talkcontribs)

More potential privileged groups

10
Krenair (talkcontribs)

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
Ymblanter (talkcontribs)

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


This post was hidden by Krenair (history)
This post was hidden by Krenair (history)
This post was hidden by Krenair (history)
Tgr (talkcontribs)

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

JogiAsad (talkcontribs)

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

Krenair (talkcontribs)

@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)
CKoerner (WMF) (talkcontribs)

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

Krenair (talkcontribs)

So we're still missing:

  • Pathoschild's/global deleter
  • Researchers
Reply to "More potential privileged groups"
Xaosflux (talkcontribs)

Global Sysops? (Who are also interface admins)

Jdforrester (WMF) (talkcontribs)

I think they will get caught automatically by the "has editsitejs" check, but yes, good point.

Tgr (talkcontribs)

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.

Warn, not require? Remember previous RfC??

1
Gryllida (talkcontribs)

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.
Reply to "Warn, not require? Remember previous RfC??"