My current patchset requires sysops, bureaucrats, and bots (all the default groups with privileges) to have 8-byte long passwords, while keeping the default for all users as 1. This is closer to the iSEC recommendation, and close to the examples given on http://en.wikipedia.org/wiki/Password_strength, which is sited when we say sysops should have "strong passwords" (http://en.wikipedia.org/wiki/Wikipedia:Administrators).

Is 8-byte minimum passwords for privileged accounts as the default a problem for anyone?

CentralAuth patch coming soon for global groups.

@csteipp If an existing account has a password that is now considered "weak", what will be the user experience?

Also, just out of curiousity, is it really "8 bytes", and not "8 characters"? And if so, is that a good thing?

In T94774#1257281, @ksmith wrote:

@csteipp If an existing account has a password that is now considered "weak", what will be the user experience?

@ksmith, for users affected by this patch (i.e., sysops, bot accounts, and bureaucrats) if they have a password less than 8-bytes/characters, they will still be logged in when they enter their username and password, but will be redirected to the change-password form and asked to update their password. On that page, they can click "cancel" and continue back to the page where they logged in from (normal login flow), but they will be prompted for a password change each time they login.

For global accounts, my idea is that Stewards, Staff, and other high-privilege accounts will also have similar policies, but after some amount of time, we'll raise the minimum length to login to be 8 characters too, so users with weak passwords will no longer be able to login-- they will just get a password-failed message when they try. That's in case we have users with these high privileges who get used to just clicking cancel each time they login, instead of changing their password. But I'm happy to do that in a few months, so we don't surprise anyone with it.

Also, just out of curiousity, is it really "8 bytes", and not "8 characters"? And if so, is that a good thing?

Bytes, because that is the metric we've previously used in mediawiki, and was trying to keep things the same for most users. We can easily create a "Minimum Characters" rule for cases where they are not, but it would probably be less than 8, since 8 Chinese characters is a short sentence.

In messaging, we probably should probably say, "8 characters long (or 8 bytes, if you're using non-ascii characters)".

Change 208695 had a related patch set uploaded (by CSteipp):
Add global password policies

https://gerrit.wikimedia.org/r/208695

Change 206156 merged by jenkins-bot:
Password validity by policy per group

https://gerrit.wikimedia.org/r/206156

• https://gerrit.wikimedia.org/r/206156 (branch master): MW-1.26-release, WMF-deploy-2015-06-16_(1.26wmf10)

Change 217412 had a related patch set uploaded (by CSteipp):
Match group password policies to previous values

https://gerrit.wikimedia.org/r/217412

In T94774#1257641, @csteipp wrote:

In T94774#1257281, @ksmith wrote:

@csteipp If an existing account has a password that is now considered "weak", what will be the user experience?

@ksmith, for users affected by this patch (i.e., sysops, bot accounts, and bureaucrats) if they have a password less than 8-bytes/characters, they will still be logged in when they enter their username and password, but will be redirected to the change-password form and asked to update their password. On that page, they can click "cancel" and continue back to the page where they logged in from (normal login flow), but they will be prompted for a password change each time they login.

For global accounts, my idea is that Stewards, Staff, and other high-privilege accounts will also have similar policies, but after some amount of time, we'll raise the minimum length to login to be 8 characters too, so users with weak passwords will no longer be able to login-- they will just get a password-failed message when they try. That's in case we have users with these high privileges who get used to just clicking cancel each time they login, instead of changing their password. But I'm happy to do that in a few months, so we don't surprise anyone with it.

@csteipp, is the code to handle this redirection already in place in some other portion of the application? I didn't see it in your patch.

In T94774#1359390, @dpatrick wrote:

@csteipp, is the code to handle this redirection already in place in some other portion of the application? I didn't see it in your patch.

SpecialUserLogin is where the login flow is generally managed. So there you can see the special handling of when checkPasswordValidity returns an error vs fatal, along with password expiration handling.

Change 217412 merged by jenkins-bot:
Match group password policies to previous values

https://gerrit.wikimedia.org/r/217412

Change 208695 merged by jenkins-bot:
Add global password policies

https://gerrit.wikimedia.org/r/208695

• https://gerrit.wikimedia.org/r/208695 (branch master): WMF-deploy-2015-06-30_(1.26wmf12)

I'm looking at the original recommendation, and it seems like the goal is "as difficult as possible for a legitimate user to type on a mobile device", while still maintaining the old 'feature' of "can be cracked quickly by any script that can handle L33t-speak like 'Passw0rd!'" (which would be a legitimate password under that scheme).

Why not a passphrase, instead of requiring people on mobile devices to use two "keyboards" plus meta keys? Short sentences are easy to remember, and a minimum of 12 characters is harder to guess than 8 plus a couple of special characters.

In T94774#1412037, @Whatamidoing-WMF wrote:

I'm looking at the original recommendation, and it seems like the goal is "as difficult as possible for a legitimate user to type on a mobile device", while still maintaining the old 'feature' of "can be cracked quickly by any script that can handle L33t-speak like 'Passw0rd!'" (which would be a legitimate password under that scheme).

I'm not exactly sure what you're saying here, but in general, we do not want privileged accounts to be crackable, even assuming an attacker has gotten a hold of our password hashes. So we'll start with password length, and a blacklist of common passwords will likely be put in place. The other recommendations from iSec are the usual "best practice" list, but there's enough research that puts their effectiveness in practice in doubt that I doubt we would implement them for standard user accounts. So yes, long pass-phrases I think are a fine strategy.

The other recommendations from iSec are the usual "best practice" list, but there's enough research that puts their effectiveness in practice in doubt

That's exactly my concern. The usual best-practice list isn't very good, but it does create problems for typing on some devices.

Could we do something that is simultaneously better than best-practice (e.g., a longer minimum length) and slightly less annoying to the people who have to type it (e.g., not requiring that every password include *all four* of the possible 'types' of characters in the 'best-practice' list)? Or maybe even have an algorithm that compares complexity against length, so that a 30-character passphrase doesn't require any "special" characters, but an 8-byte one does?

I raise you "correct horse battery staple" and all his friends. https://xkcd.com/936/

I agree with @Whatamidoing-WMF. The approach of mandating a certain number of characters in each set, rather than an entropy-based approach, forces users to create passwords that they can't remember but isn't much harder for a machine to crack by brute-force. And how are the rules gonna be implemented if someone uses non-ASCII characters? I worry that this switch actually forces some users to switch to less secure passwords because their current passwords are high-entropy but don't contain the requisite set of characters.

The joys of not reading code - I am unable to determine exactly what is being changed here, other than that it will undoubtedly affect groups of which I am a member. Can things be spelled out more clearly here, please?

*Is this an imminent change, or is this phase 1 where the ability to enforce password standards can be made group specific?
*Assuming that (at least some) members of (specific, undefined) groups are about to have to change their passwords:

• • Precisely which user groups are affected, and how many people are in each group?
  • Have the users in these groups been notified in advance of this change?
  • What *are* the new standards for password, besides 8-byte? Will numbers/symbols/upper AND lower case all be required for all passwords in these groups?
  • What percentage and number of users in the proposed affected groups *currently* use passwords that would not meet the new standard?
• Will all users in the affected groups need to change their passwords whether or not their current password meets the new standard?
  • Is there any evidence at all to indicate that people's current passwords have been compromised through password hacking (as opposed to lack of password security on the part of the individual) or are we dealing with a hypothetical problem rather than a real problem?

I'd really like to see the last two questions answered before proceeding forward, and the rest of the questions answered before any implementation. Lack of advance notice to affected users (if it includes administrators, we're likely talking several thousand accounts) should be considered a blocker.

As an aside, I found it humorous to see the WMF security guy using http in his links to Wikipedia :-)

Risker/Anne

Let me clarify a couple bits:

As the title of this task says, the code changes are to make it so that it's possible to set password policies by group. I'll update the description to more clearly say that those are examples of policies that it should be possible to define per group.

After this code is live on all wikis, we can then have the conversation of what policy makes sense for specific groups. In the past, we've discussed raising minimum password length for everyone (since that was the only policy enforcement available to us), but nearly every conversation resulted in a compromise balancing something reasonably strong to protect admins, but not burdening users with no rights. The result of the code changes associated with this task is that we no longer have to compromise on either side, we can define them separately.

As a followup, we should then have a conversation of what is appropriate for different groups. I've been slow getting individual tasks opened for each group's policy, but I'll add those now. I believe that we do need to set stronger policies for users who have access to checkuser data, and interface editing rights. But we can now address those individually.

In the next month, I'd like to get Staff (T104370) and Stewards (T104371) addressed, and work out a policy/timeline for Ombudsmen (T104372) and anyone with checkuser (T104373) by the end of July.

In T94774#1413033, @deryckchan wrote:

I agree with @Whatamidoing-WMF. The approach of mandating a certain number of characters in each set, rather than an entropy-based approach, forces users to create passwords that they can't remember but isn't much harder for a machine to crack by brute-force. And how are the rules gonna be implemented if someone uses non-ASCII characters? I worry that this switch actually forces some users to switch to less secure passwords because their current passwords are high-entropy but don't contain the requisite set of characters.

Do read the implementation. Adding specific checks is now pretty trivial, so if you have suggestions, they can be implemented as a simple config change. It sounds like you're proposing a policy of minimum entropy?

Thank you for your clarification, csteipp; it's very helpful. I've sent an email to the checkuser mailing list to alert the checkusers who subscribe (and also includes most if not all stewards) with links to the applicable phab tasks so that the discussion (if any) can start for those groups. -I'm pretty sure just about everyone in those groups would already meet the 8-byte requirement, but one never knows.

In T94774#1414321, @Risker wrote:

The joys of not reading code - I am unable to determine exactly what is being changed here, other than that it will undoubtedly affect groups of which I am a member. Can things be spelled out more clearly here, please?

*Is this an imminent change, or is this phase 1 where the ability to enforce password standards can be made group specific?

This! So yes, this is "phase 1", and everything can be group specific now.

*Assuming that (at least some) members of (specific, undefined) groups are about to have to change their passwords:

• Precisely which user groups are affected, and how many people are in each group?

Let's start with the Staff and Stewards case. 65 users, if I counted right.

• Have the users in these groups been notified in advance of this change?

They will be. Staff and Stewards are easy to communicate to, so I was planning to email a notice about 1 week before the change. The initial change will only prompt users to change their password on login if they aren't compliant, so there won't be a real affect on users until we change the minimum length to login. My idea is to make that change 1 or 2 weeks after the first change for Staff and Stewards. For a larger group like Checkusers, we would probably give them at least the 30 days that they can stay logged in via cookie.

• What *are* the new standards for password, besides 8-byte? Will numbers/symbols/upper AND lower case all be required for all passwords in these groups?

Let's discuss! 8-byte minimum length seems like it would be a safe policy that everyone in these groups will likely already comply with. A further check to blacklist the most common passwords I think would be a good addition, but let me dig up some research on that.

• What percentage and number of users in the proposed affected groups *currently* use passwords that would not meet the new standard?

To research this, we would have to crack our existing database. I'm conflicted on whether that's something we should do or not.

• Will all users in the affected groups need to change their passwords whether or not their current password meets the new standard?

Just users who's passwords don't meet the new standard. And further, these users will (initially) still be able to login, they will just be prompted to change their password until they do.

• Is there any evidence at all to indicate that people's current passwords have been compromised through password hacking (as opposed to lack of password security on the part of the individual) or are we dealing with a hypothetical problem rather than a real problem?

We have seen password brute forcing of accounts, including admin accounts. However, to my knowledge, we have never tied the compromise of an admin's account directly to brute forcing of their password. However, going back to events like https://en.wikipedia.org/wiki/Wikipedia:Wikipedia_Signpost/2007-05-07/Admins_desysopped, 2 of the four admins admitted to having weak passwords, which may have been the the way they were compromised.

I'd really like to see the last two questions answered before proceeding forward, and the rest of the questions answered before any implementation. Lack of advance notice to affected users (if it includes administrators, we're likely talking several thousand accounts) should be considered a blocker.

As an aside, I found it humorous to see the WMF security guy using http in his links to Wikipedia :-)

Risker/Anne

In T94774#1415145, @csteipp wrote:

In T94774#1414321, @Risker wrote:

• What percentage and number of users in the proposed affected groups *currently* use passwords that would not meet the new standard?

To research this, we would have to crack our existing database. I'm conflicted on whether that's something we should do or not.

Couldn't we add something that computed this on login when we have the plain text password available? Granted it would take 30+ days to get a full sample of the active population. Since we have individual salts and strong hashes these days a brute force crack wouldn't be cheap even if you decided it was a good idea (and it's not).

In T94774#1415145, @csteipp wrote:

In T94774#1414321, @Risker wrote:

• What percentage and number of users in the proposed affected groups *currently* use passwords that would not meet the new standard?

To research this, we would have to crack our existing database. I'm conflicted on whether that's something we should do or not.

We could also add some logging during log in to get basic stats on users with weak passwords.

In T94774#1415248, @Legoktm wrote:

We could also add some logging during log in to get basic stats on users with weak passwords.

Sounds like a good plan to me!

Change 222025 had a related patch set uploaded (by CSteipp):
Log privileged users with short passwords

https://gerrit.wikimedia.org/r/222025

In T94774#1415859, @gerritbot wrote:

Change 222025 had a related patch set uploaded (by CSteipp):
Log privileged users with short passwords

https://gerrit.wikimedia.org/r/222025

Well, I won't be one of those privileged users who gets logged, but just to be clear...where will this be logged, and who will have access to the log? Will it include the specific usernames?

(Yes, I can't imagine CSteipp making it accessible, but this is just to avoid any concerns.)

In T94774#1415950, @Risker wrote:

In T94774#1415859, @gerritbot wrote:

Change 222025 had a related patch set uploaded (by CSteipp):
Log privileged users with short passwords

https://gerrit.wikimedia.org/r/222025

Well, I won't be one of those privileged users who gets logged, but just to be clear...where will this be logged, and who will have access to the log? Will it include the specific usernames?

(Yes, I can't imagine CSteipp making it accessible, but this is just to avoid any concerns.)

Well, looking at the first patch set (which is definitely not final - indeed I've brought up issues there which will require changes), it'll go into the badpass log, available to people with shell access to fluorine or logstash access (i.e., these people have signed NDAs). Pretty sure most of these people would have the technical ability to impersonate you on-wiki without needing silly things like passwords anyway.

It does not include usernames, but it does list some of the highly privileged groups you are in (currently: global staff, local or global steward, global ombudsmen, local checkuser, local sysop) - in some cases this combination could be unique, especially for ombudsmen (since there's so few of those). It also logs whether the password is <4 characters or 4-7 characters.

the 30 days that they can stay logged in via cookie.

This is probably (finally, thankfully) going to be much longer than 30 days sometime soon: T68699: Increase "remember me" login cookie expiry from 30 days to 1 year on Wikimedia wikis

I firmly support the plan to be able to set different policies for different groups. Additionally, I support increasing the minimum password length for the most sensitive groups as an incremental improvement. Even if people later decide that requiring some combination of meta keys, symbols, and numerals is appropriate, we would be taking a step in the right direction by disallowing very brief passwords.

In the end, I trust Csteipp to sort out whether dictionary-word proposal is worthwhile or just security theater. If he decides that it's valuable, then I nominate "correct horse battery staple" for inclusion in the banned-passwords list. :-)

In T94774#1416024, @Krenair wrote:

It does not include usernames, but it does list some of the highly privileged groups you are in (currently: global staff, local or global steward, global ombudsmen, local checkuser, local sysop) - in some cases this combination could be unique, especially for ombudsmen (since there's so few of those). It also logs whether the password is <4 characters or 4-7 characters.

We log logins in centralauth.log so you could probably match up users based on timestamps.

Change 223702 had a related patch set uploaded (by CSteipp):
Add global password policies

https://gerrit.wikimedia.org/r/223702

Change 223702 merged by jenkins-bot:
Re-add global password policies

https://gerrit.wikimedia.org/r/223702

Change 251009 had a related patch set uploaded (by CSteipp):
Re-add global password policies

https://gerrit.wikimedia.org/r/251009

Change 251009 abandoned by CSteipp:
Re-add global password policies

https://gerrit.wikimedia.org/r/251009

Change 222025 merged by jenkins-bot:
Log privileged users with short passwords

https://gerrit.wikimedia.org/r/222025