Talk:Requests for comment/Password policy for users with certain advanced permissions

"Password cannot be the words 'Wiki', 'MediaWiki' or the name of the project in question."[edit]

Can we just say "or the name of any Wikimedia project"? SUL has changed the landscape. The way this is currently worded, I'd interpret this sentence to mean that I could use "Wikisource" as my password and be able to log in at any project *except Wikisource.* Risker (talk) 17:05, 13 December 2015 (UTC)[reply]

yeah, i know this is kind of unideal, but right now the code only checks the name of the current wiki project where the login is being processed. Its a bit of an artifact of the code in question being targeted both at generic mediawiki usage (where mediawiki doesnt know what the names of other wikis are) and wikimedia usage. Ideally at some future point it would do as you suggest. BWolff (WMF) (talk) 18:35, 13 December 2015 (UTC)[reply]

We can simply add the wmf project names to the blacklist. Platonides (talk) 00:18, 14 December 2015 (UTC)[reply]

"Once the restrictions are put into place, users who don't have a strong enough password will be asked to change it next time they log in."[edit]

How will be determined that one currently uses a password that doesn't qualify? --Krd 18:57, 13 December 2015 (UTC)[reply]

When you log in, you supply your password to wikimedia servers (so it can be hashed and compared against the saved hash of your password). At that point it is checked against the strength requirements. We never store the plaintext version of the password, but we do recieve it as part of the login process. BWolff (WMF) (talk) 19:53, 13 December 2015 (UTC)[reply]

Thank you. Appears reasonable to me. --Krd 06:12, 14 December 2015 (UTC)[reply]

People with non-secure passwords prove their untrustworthiness with this behaviuor[edit]

If you have a non-secure password, you prove beyond any doubt that you are untrustworthy for any access level above simple editor. That's a nobrainer, it's plain a matter of course. Grüße vom Sänger ♫^(Reden) 10:51, 14 December 2015 (UTC)[reply]

"Users who don't have a strong enough password will be asked to change it next time they log in"[edit]

Is there more information on the proposed mechanics of this? With hashing of existing passwords it should not be known if a "password change is required"; where will this password checking take place? (e.g. will additional information be processed prior to hashing?). xaosflux ^Talk 16:57, 14 December 2015 (UTC)[reply]

Look in this paragraph to see the answer. It's looked at before hashing. Grüße vom Sänger ♫^(Reden) 17:16, 14 December 2015 (UTC)[reply]

So on every logon it is being evaluated against the blacklist and parameters? We should not otherwise KNOW if their password is "weak" or not currently. xaosflux ^Talk 18:48, 14 December 2015 (UTC)[reply]

Correct. We can only check your password meets these requirements during login, when we have the unhashed version available. If your password is weak enough, in principle a password cracking program would eventually reverse the hash. So we could potentially run such a program as an auditing step to make sure that nobodies password is weak enough to fall to such an attack (The EN Wikipedia RFC called for "auditing" en wiki admin accounts. Im not 100% sure what is planned in that direction, but checking that no admin accounts fall to popular cracking programs in a short amount of time would be the most obvious way to "audit" account security). BWolff (WMF) (talk) 19:55, 14 December 2015 (UTC)[reply]

BWolff, it was the intention of my previous question in another section above if such a cracking is intended. Please give a definite answer to this question. Thank you. --Krd 20:06, 14 December 2015 (UTC)[reply]

PS: If I'm not mistaken the check at login had to be done only once for every affected user, because afterwards it is done during the password changes. Could you point us to the related piece of code so that this can be verified? Thx. --Krd 20:09, 14 December 2015 (UTC)[reply]

User:Krd: Sorry for the confusion. Cracking will not be used to enforce the restrictions in this policy. Its possible that cracking will be used for other security goals (english wikipedia has asked us to "audit" the password security of their admins. Its not entirely clear to me what that actually will mean, but running a password cracker seems like one of the most obvious ways of doing such an "audit"). The code is currently at https://github.com/wikimedia/mediawiki/blob/master/includes/password/PasswordPolicyChecks.php and https://github.com/wikimedia/mediawiki/blob/master/includes/password/UserPasswordPolicy.php. We check every login as the users' groups can change. BWolff (WMF) (talk) 20:36, 14 December 2015 (UTC)[reply]

We haven't decided how to go about auditing existing passwords for enwp admins, as they requested on their RFC. We need to work out with legal a specific plan that balances identifying risks with protecting our admins' privacy. It will likely be some combination of checking known password dumps from other compromised sites (this is how the enwp administrator accounts were recently compromised) and possibly some password cracking. For password cracking, our password hash is extremely computationally intensive. Even checking a moderate list of common passwords for all enwp administrators will takes weeks and requires a fair amount of planning, so the returns on doing that regularly will diminish quickly. CSteipp (WMF) (talk) 00:12, 16 December 2015 (UTC)[reply]

Grammar in proposal[edit]

Are you sure that the following sentence is grammatical correct?

To that end, we would like to propose that the password requirements be adjusted for users who have the editinterface right (Can edit pages in the MediaWiki namespace, like MediaWiki:Common.js), users who have a right that is subject to Access to nonpublic information policy[1], or are allowed to add other users to such groups.

In my opinion, it should concern to three user groups like this:

To that end, we would like to propose that the password requirements be adjusted for users who have the editinterface right (Can edit pages in the MediaWiki namespace, like MediaWiki:Common.js), users who have a right that is subject to Access to nonpublic information policy[1], or users who are allowed to add other users to such groups.

On the other side, such a proposal could be simplified in order to be understood by users with en-1/2 knowledges. -- Juetho (talk) 09:19, 25 December 2015 (UTC)[reply]

Changed. Please feel free to edit the proposal for grammar. BWolff (WMF) (talk) 21:54, 25 December 2015 (UTC)[reply]

Thank you. I don't feel to be able to do so. I can read and partially talk in en-2 (Babel), but check in en-1 only. I stumbled while improving the German translation (punctuation above all) and noticed here. -- Juetho (talk) 08:02, 26 December 2015 (UTC)[reply]

For how long is this supposed to run?[edit]

I fail to see any deadline on the front page, for how long is this going to run before it's decided? I'm used to Meinungsbilder in the deWP, and those are only valid with a end date. I'm not familiar with the customs over here, but open end seems a bit futile. --Grüße vom Sänger ♫^(Reden) 12:14, 8 January 2016 (UTC)[reply]

That's a good question. I'm not sure if there are global customs for this sort of thing, but given that the rfc has seemed to slow down, lets arbitrarily pick a line in the sand and say it should be closed in 1 week on Jan 20. BWolff (WMF) (talk) 01:00, 14 January 2016 (UTC)[reply]

I would suggest that just about anybody could close this at anytime as there are over 150 users expressing support and less than 30 opposing. Beeblebrox (talk) 20:31, 21 January 2016 (UTC)[reply]

yeah, it doesn't exactly seem controversial. That said, I would prefer if someone who is not "me", closes it. BWolff (WMF) (talk) 22:55, 21 January 2016 (UTC)[reply]

maximum[edit]

Is there a maximum length for a password in wikimedia? Since phrases are permitted the password could be long. 64 bytes is not unheard of --DaleDe (talk) 18:39, 8 February 2016 (UTC)[reply]

I asked about this myself on the comments page; BWolff's answer, "upper limit on password length is 4096 bytes. Which should be enough for anyone, unless you use an epic pass-poem." --Pi zero (talk) 19:44, 8 February 2016 (UTC)[reply]