Topic on Talk:Wikimedia Security Team/Password strengthening 2019

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.