Page MenuHomePhabricator

Change password length requirement and ensure enforcement for privileged users (from 8 to 10)
Closed, ResolvedPublic3 Story Points

Description

👯‍♂️ See also: T211622: Change password length requirement and ensure enforcement for non-privileged users (from 1 to 8)


We need to modify the required lengths of passwords. Specifically, these changes should be made:

  • Increase minimum password length for all privileged* accounts from 8 to 10.
  • When an admin logs in with a password that does not match the requirements, they should see a notification that their password does not match the requirements.
    • This notification already exists, but should up updated to display the new accurate information.

Notes

  • The defaults for password policy are here in DefaultSettings.php. Some policies are changed dynamically in CommonSettings.php.
  • We will need to ensure the error messages work as described in the requirements above.
  • We can provide new defaults in the MW install and we can confirm that the wikis we maintain honor those defaults. It's possible that some wikis will have changed these defaults or provided overrides. This might be a good place for communication.
  • Permissioned groups that need a minimum of 10: Administrators, Interface administrators, Bureaucrats, Oversighters, Central notice administrators, Global renamers, WMF Office IT, WMF Support and Safety, CheckUsers, Staff, and Stewards.

Further research and comments are located in: T208065 (That task includes the password blacklist work which is handled elsewhere and not part of this task.)


Acceptance criteria

  • New password minimum length of 10 for privileged account is enforced on login
  • Error messages display as needed and display accurate information

Related Objects

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes
Reedy added a comment.Oct 30 2018, 3:46 PM

Yeah, I would imagine so. Some of the messages are in this area are known to be clunky :)

putnik added a subscriber: putnik.Oct 31 2018, 12:16 AM

This is basically going to force people into having bad passwords. Length is not a good indicator of password strength, and the current requirements prohibit the strongest memorable passwords. Forcing people to have less memorizable passwords means that they'll use more easily guessable passwords.

Is there any intention to have an RfC about this?

This is basically going to force people into having bad passwords. Length is not a good indicator of password strength, and the current requirements prohibit the strongest memorable passwords. Forcing people to have less memorizable passwords means that they'll use more easily guessable passwords.

Enforcing a minimum password length protects against brute-force exhaustive password searches, e.g. in cases of data breaches where hashed passwords are leaked. A minimum password length of 8 characters does not prevent any strong passwords from being used; modern GPUs can brute-force arbitrary MD5-hashed 8-character passwords in seconds, and other hashing algorithms don't fare much better (see for example https://thycotic.force.com/support/s/article/Calculating-Password-Complexity, which shows that cracking an 8-character alphanumeric password hashed with SHA512, using a GPU, would take only about 5 days, and far less if the attacker has access to larger computational resources [not at all an unreasonable assumption given the availability of Amazon AWS and similar cloud computing services]).

The standard security response to "what about memorable passwords" is to stop trying to remember your passwords and instead use a password manager to generate and manage unique passwords for all your accounts.

Length is not a good indicator of password strength, and the current requirements prohibit the strongest memorable passwords.

Neither is complexity

Is there any intention to have an RfC about this?

I'm meeting with @CKoerner_WMF tomorrow to discuss how to hold a public, on-wiki discussion about our proposed changes.

In addition to requiring a longer length, we are planning to expand the library of commonly used passwords to 100,000 (currently is 100) — T151425 — There are many schools of thought for password security, but I think we can all agree that 1-character length passwords are far less than ideal.

Lofhi added a subscriber: Lofhi.Oct 31 2018, 5:17 PM

Please don't forget assigning component-related projects to your tasks!

While we review all the messages with the new UI, it seems appropriate to also use the opportunity to evangelize about password managers...

TBolliger updated the task description. (Show Details)Nov 15 2018, 6:16 PM

A minimum password length of 8 characters does not prevent any strong passwords from being used

The current policy of prohibiting passwords that are only lowercase letters prohibits the strongest passwords (eg correct horse battery staple) from being used. Adding extra requirements of this sort basically means that people will start recording their passwords in non-secure locations.

The standard security response to "what about memorable passwords" is to stop trying to remember your passwords and instead use a password manager to generate and manage unique passwords for all your accounts.

The very few people doing that are already beyond having to worry about this. The only reason to have password requirements are for people who aren't using a password manager.

A minimum password length of 8 characters does not prevent any strong passwords from being used

The current policy of prohibiting passwords that are only lowercase letters prohibits the strongest passwords (eg correct horse battery staple) from being used. Adding extra requirements of this sort basically means that people will start recording their passwords in non-secure locations.

The strength of those passwords depends on a lot of assumptions, and I will always dispute the idea that they could be stronger than passwords generated by a password manager. In addition, using them does not help with the problem of remembering passwords when you're using a different password for every account as you're supposed to, across potentially dozens or even hundreds of different accounts. Nothing about this complaint depends on a minimum password length of less than 8 characters; if used correctly, xkcd-style passwords will always be far longer than 8 characters, so such a length requirement would not affect them regardless. And anyone who is apt to write their passwords down or otherwise store them in an insecure fashion is probably already doing so, regardless of any password requirements in place on any particular service. Again, the correct response to all of this is to encourage the use of password managers, not to simply throw our hands up and say "we can't do anything so we won't do anything".

The standard security response to "what about memorable passwords" is to stop trying to remember your passwords and instead use a password manager to generate and manage unique passwords for all your accounts.

The very few people doing that are already beyond having to worry about this. The only reason to have password requirements are for people who aren't using a password manager.

The point to recommending a password manager is not to convince those who already use one, but to help educate and convince those who do not. Minimum password requirements still serve a purpose even if every person with an account uses a password manager, since all managers I'm aware of allow you to choose your own passwords or generate arbitrarily weak passwords.

Reedy added a comment.Nov 22 2018, 1:21 AM
This comment was removed by Reedy.
Reedy added a comment.Nov 22 2018, 1:23 AM

Unless I’ve missed something... where are we proposing to stop lowercase only passwords?

That’s a complexity requirement that afaik we’re not proposing

Unless I’ve missed something... where are we proposing to stop lowercase only passwords?
That’s a complexity requirement that afaik we’re not proposing

Ack. Apparently I misunderstood the password requirements. Sorry.

TBolliger triaged this task as Normal priority.Nov 26 2018, 6:23 PM
TBolliger updated the task description. (Show Details)Nov 29 2018, 6:18 PM
TBolliger set the point value for this task to 3.Nov 29 2018, 7:13 PM
Stryn added a subscriber: Stryn.Nov 29 2018, 8:59 PM
TBolliger raised the priority of this task from Normal to High.Dec 5 2018, 8:03 PM
dmaza claimed this task.Dec 6 2018, 5:53 PM
dmaza moved this task from Ready to In progress on the Anti-Harassment (AHT Sprint 35) board.
Tgr added a subscriber: Tgr.EditedDec 6 2018, 10:20 PM

This feels a bit rushed. Maybe I am just not aware that the preparations already happened, in which case apologies in advance, but otherwise I would recommend pushing out the date by a month or so and doing more groundwork.

  • As a user neither the password policy page nor the project page is useful to me. I don't care how many popular passwords are blacklisted as that information is not directly useful to me, nor about organizational details around the policy. What I would care about is best practices for choosing strong passwords or advice on what password manager to use.
  • There is barely a mention of password reuse, even though that is the actual attack that has prompted this. That should get much more emphasis.
  • Currently users only find out about the minimum length requirement when they enter a short password and it fails. That's not great. (Fun fact: the AJAX check-as-you-type feature does not work on the mobile registration page.)
  • How are people going to find the password policy page? I guess you'll add a link to the footer info block? (Again, not a thing in the current mobile design.) What timeframe will translators have to work with it?
  • The list of privileged account types is not very accurate. Not that it matters much but it will probably cause people to freak out. T210192#4790771 has a fairly accurate list.
  • Raising the minimum length requirement for existing (admin) accounts means a new login step will be triggered. Do the mobile apps support that (at least to the extent of sending the user to the web interface to deal with it)?
  • Similarly, bots using the old login API will break. This is mostly relevant for supervised tools like Pywikibot and AWB (hopefully people don't use non-interactive bots with admin accounts) - both of those support bot passwords so people not using that kind of deserve the breakage, but even so, there will probably be plenty of bot ops who are affected and miss the announcement (it's amazing how many people miss announcements that involve banner campaigns and massive village pump messaging), so maybe worth temporarily customizing the old login API's error message (right now it's something like "Authentication requires user interaction, which is not supported by action=login").

Most importantly, this will force a lot of users to pick a new password, and they will probably not do that again for a long time, so this is our opportunity to guide them to use strong passwords, and I feel we don't do much in that regard. I still think T189641: Service for checking the Pwned Passwords database is worth doing first. (Again, password reuse is the actual attack we are dealing with, not brute-forcing of short or common passwords, so it's unclear to me how the current policy would achieve much. Of course there are other potential attacks to defend against and the new checks are definitely a good idea but none of those other threats are so urgent that the change would have to be done, consultation and all, in a week.) T32574: Display a password strength bar/T151011: Add password generator to account creation / password change form is another thing that would probably improve password strength and is not too hard to do.

This feels a bit rushed. Maybe I am just not aware that the preparations already happened, in which case apologies in advance, but otherwise I would recommend pushing out the date by a month or so and doing more groundwork.

This has been in flight for a bit.

  • As a user neither the password policy page nor the project page is useful to me. I don't care how many popular passwords are blacklisted as that information is not directly useful to me, nor about organizational details around the policy. What I would care about is best practices for choosing strong passwords or advice on what password manager to use.
  • There is barely a mention of password reuse, even though that is the actual attack that has prompted this. That should get much more emphasis.

There is a supporting blog post/Security awareness piece coming out with this announcement. Content is written and we're working with the digital media folks to get that out. In a nutshell we introduce 6 rules for better credentialing that include how to create a good password (passphrase), passwd mgrs to use, why you shouldn't recycle passwds and others. All this started before all the recent incident business and is not in response to nor intended to be a complete solution to those issues. It's just general security improvements.

Most importantly, this will force a lot of users to pick a new password, and they will probably not do that again for a long time, so this is our opportunity to guide them to use strong passwords, and I feel we don't do much in that regard. I still think T189641: Service for checking the Pwned Passwords database is worth doing first. (Again, password reuse is the actual attack we are dealing with, not brute-forcing of short or common passwords, so it's unclear to me how the current policy would achieve much. Of course there are other potential attacks to defend against and the new checks are definitely a good idea but none of those other threats are so urgent that the change would have to be done, consultation and all, in a week.) T32574: Display a password strength bar/T151011: Add password generator to account creation / password change form is another thing that would probably improve password strength and is not too hard to do.

Agreed, the idea here is to encourage good credential habits via the awareness piece and remove the 1 character passwd. I'm not opposed to T189641: Service for checking the Pwned Passwords database but looking thru that ticket I think it'll be a while before that's ready.

CKoerner_WMF added a comment.EditedDec 7 2018, 5:33 PM

@Tgr, thanks for the feedback.

This feels a bit rushed. Maybe I am just not aware that the preparations already happened, in which case apologies in advance, but otherwise I would recommend pushing out the date by a month or so and doing more groundwork.

I started working with AHT and Security at the beginning of November (T205931#4714403). The attacks on vulnerable privileged accounts has escalated since then. We've worked as diligently and quickly as possible to get the word out and the new policy in effect. The timeline isn't as long as even I'd like, but given that the alternative option was to not notify users of the risk (many admins are already aware of the headache) and wait another month over a popular holiday time for any action, we erred on a shorter timeframe. Ideally yes, I'd like more time too. The vandals aren't giving us that. :/

As a user neither the password policy page nor the project page is useful to me. I don't care how many popular passwords are blacklisted as that information is not directly useful to me, nor about organizational details around the policy. What I would care about is best practices for choosing strong passwords or advice on what password manager to use.
There is barely a mention of password reuse, even though that is the actual attack that has prompted this. That should get much more emphasis.
Currently users only find out about the minimum length requirement when they enter a short password and it fails. That's not great. (Fun fact: the AJAX check-as-you-type feature does not work on the mobile registration page.)

As John mentioned, there is a more general "password best practices" message coming shortly to the Wikipedia blog. The project page was written to inform people of the Wikimedia-specific changes and rational. It wasn't intended to be a general best practices page as written. I think some of your suggestions could be incorporated in the project page. There are other pages (and information in general) that cover best password practices. If @JBennett is OK with that I can update the page perhaps with some links to more information. Like this blog post which talks about the standards we've adopted. Thank you for the suggestions.

How are people going to find the password policy page? I guess you'll add a link to the footer info block? (Again, not a thing in the current mobile design.)

Given all that, I've notified as many folks as I could think of to give as much notice as possible (T205931#4804486). There are a few community-managed pages like Wikipedia:Password_strength_requirements and Meta:Policies_and_guidelines that I have on my radar, but updating them directly is something I don't want to do with my staff account. I'll leave notes on the talk pages suggesting review and inclusion of the new password information. If you can think of other venues please advise.

What timeframe will translators have to work with it?

Infinity time. :) We rely on volunteer translators for even the big important movement-wide polices. This takes time. We made sure to have the Password policy marked for translation before announcing. As of writing we have 7 complete translations. For comparison the Privacy Policy, an older and more predominate policy, has 13 complete translations. Granted it's much longer and more complex. You can argue that it's not great, but it is what we have to work with at the moment.

The list of privileged account types is not very accurate. Not that it matters much but it will probably cause people to freak out. T210192#4790771 has a fairly accurate list.

Thanks to your and Krenair's feedback on the talk page I've updated the list. I think I'm missing a few and need to confirm they're included.

Raising the minimum length requirement for existing (admin) accounts means a new login step will be triggered. Do the mobile apps support that (at least to the extent of sending the user to the web interface to deal with it)?

I can't address this given my role as the messenger, but I wanted to make a note here that I'll follow up and ask those who can answer. :)

Similarly, bots using the old login API will break. This is mostly relevant for supervised tools like Pywikibot and AWB (hopefully people don't use non-interactive bots with admin accounts) - both of those support bot passwords so people not using that kind of deserve the breakage, but even so, there will probably be plenty of bot ops who are affected and miss the announcement (it's amazing how many people miss announcements that involve banner campaigns and massive village pump messaging), so maybe worth temporarily customizing the old login API's error message (right now it's something like "Authentication requires user interaction, which is not supported by action=login").

This is exactly the kind of technical feedback we were looking for in the announcement! Pinging @Reedy and @TBolliger. Not to put you on the spot, but could you speak more to this concern?

From a social perspective, @Tgr are you aware of any venues good for contacting bot authors? I did include the cloud mailing list in an attempt to include tool maintainers. Perhaps a message on the talk page of Wikipedia:Bots might be in order?

Most importantly, this will force a lot of users to pick a new password, and they will probably not do that again for a long time, so this is our opportunity to guide them to use strong passwords, and I feel we don't do much in that regard.

I think the blog post that is coming will cover the concerns you have around education. Again, community pages do a decent job of covering this and have for quite some time.

I still think T189641: Service for checking the Pwned Passwords database is worth doing first. (Again, password reuse is the actual attack we are dealing with, not brute-forcing of short or common passwords, so it's unclear to me how the current policy would achieve much. Of course there are other potential attacks to defend against and the new checks are definitely a good idea but none of those other threats are so urgent that the change would have to be done, consultation and all, in a week.) T32574: Display a password strength bar/T151011: Add password generator to account creation / password change form is another thing that would probably improve password strength and is not too hard to do.

The first line of the project page, "This project is one of the first steps in a long-term plan to increase the security of Wikimedia authentication and authorization systems." Emphasis mine. :) I'm confident this won't be the last you hear from Security on improvements in this regard.

On the topic of communication, one thing I've learned from this is to perhaps share early plans and ideas with other WMF staff not necessarily on the team that is actively involved in this topic area. You've given some great advice and I appreciate it.

  • Currently users only find out about the minimum length requirement when they enter a short password and it fails. That's not great. (Fun fact: the AJAX check-as-you-type feature does not work on the mobile registration page.)
  • How are people going to find the password policy page? I guess you'll add a link to the footer info block? (Again, not a thing in the current mobile design.) What timeframe will translators have to work with it?

I believe the input field in the best place, directly on the account creation page. (Password creation isn't complicated enough to necessitate reading a whole other page.) If a user provides a password that meets the requirements then they can move on unimpeded. But I agree that as we have multiple requirements, easily seeing them all at once could be helpful. Perhaps the best solution would be to add a tooltip, but that's a decision for someone on the design team: T211440: Consider displaying a tooltip by the password input field to explain password requirements

I've also created T211439: Login page doesn't show issues before submission (mediawiki.special.userlogin.signup.js does not define the mobile target)


  • Raising the minimum length requirement for existing (admin) accounts means a new login step will be triggered. Do the mobile apps support that (at least to the extent of sending the user to the web interface to deal with it)?

I tested with an admin account with a 7-character password. The desktop site explains the password minimums:

the iOS app shows a temporary password error (probably from password reset):

I do not have an Android device to test.


  • Similarly, bots using the old login API will break. This is mostly relevant for supervised tools like Pywikibot and AWB (hopefully people don't use non-interactive bots with admin accounts) - both of those support bot passwords so people not using that kind of deserve the breakage, but even so, there will probably be plenty of bot ops who are affected and miss the announcement (it's amazing how many people miss announcements that involve banner campaigns and massive village pump messaging), so maybe worth temporarily customizing the old login API's error message (right now it's something like "Authentication requires user interaction, which is not supported by action=login").

I don't know enough about bot passwords and these tools to talk about any specifics, but in general resetting a password takes a few minutes to reset and update. It'll be a minor inconvenience and hiccup for the sake of increased security.

And if these users are not permissioned, then there will be no interruption at all.

Tgr added a comment.Dec 10 2018, 11:26 AM

There is a supporting blog post/Security awareness piece coming out with this announcement. Content is written and we're working with the digital media folks to get that out. In a nutshell we introduce 6 rules for better credentialing that include how to create a good password (passphrase), passwd mgrs to use, why you shouldn't recycle passwds and others.

That's great to hear, thanks. (Even greater if people get a chance to discuss it before it is widely disseminated :)

I wouldn't put too much stock into blog posts though. Blog posts are great for reaching the fuzzy edges of the movement - people involved in outreach, affiliates, partners, people involved in meta work. I think a very small fraction of editors read it regularly; its reach is going to be tiny compared to a meta page that's linked from the right places (sitenotice, the login page, mass messages).

Also, the blog is not a great communication channel feature-wise. It cannot be translated; people cannot give feedback (comments weren't great on the old blog either, and AIUI the new blog doesn't have them at all); it is not integrated in wiki search and does not perform so well with Google search either as it does not benefit from the wikis' high pagerank, so long term discoverability suffers; only a handful of people have access, so you don't get the long term maintenance you would for a wiki page. If you want most editors to see the password generation advice, it should definitely be on a translatable meta page somewhere, and preferably linked from the account creation form.

All this started before all the recent incident business and is not in response to nor intended to be a complete solution to those issues. It's just general security improvements.

I get that this has been planned for a long time, and it's great that it's happening. It's just that but I assume that other than the recent incidents, there is no reason to roll it out in a week.

I'm not opposed to T189641: Service for checking the Pwned Passwords database but looking thru that ticket I think it'll be a while before that's ready.

It might, but it still seems to be the only thing to me that would be effective in the current incident in the short term (maybe, depending on the exact attack method).

The timeline isn't as long as even I'd like, but given that the alternative option was to not notify users of the risk (many admins are already aware of the headache) and wait another month over a popular holiday time for any action, we erred on a shorter timeframe. Ideally yes, I'd like more time too. The vandals aren't giving us that. :/

I can totally see the point of trying to protect patrollers from a Christmas spent with vandal fighting, but as I said I don't think password policy changes are effective for quick short-term mitigation. The attack is mainly based on hijacking extended confirmed accounts, and the changes don't affect those (and even if they did, many of them are inactive). Even for admins, what's the ratio of users who will not check messages in the next 30 days because they are on vacation or something? user_touched is not a perfect measure, but going by that, more than half of enwiki admins were inactive in the last 30 days.

If you can think of other venues please advise.

I can't (short of using banners), that's pretty good coverage. The account creation page and the password change pages (there is one you reach from preferences and one you get at login) should probably have a pointer though, those are the most reliable places for making sure users learn about choosing good passwords.

Not to put you on the spot, but could you speak more to this concern [bots using the old login API]?

Sorry, I was wrong about that one. The concern was that the old API gives a very generic error message when the login cannot succeed (because it would involve a multi-step form such as 2FA or password change, and the old API has no way of handling that), and we'd want to explain the user that they need change their password. But that error message actually mentions bot passwords, which is probably the best that can be done in that situation, so no change needed there.

From a social perspective, @Tgr are you aware of any venues good for contacting bot authors? I did include the cloud mailing list in an attempt to include tool maintainers. Perhaps a message on the talk page of Wikipedia:Bots might be in order?

Wikipedia:Bots/Noticeboard and its interwikis would be the main one (if that doesn't exist fall back to Wikipedia:Bots). The cloud list is a good idea; other than that maybe reach out to the main framework maintainers (like AWB/PWB)? Although per above it might not really be necessary.

The first line of the project page, "This project is one of the first steps in a long-term plan to increase the security of Wikimedia authentication and authorization systems." Emphasis mine. :) I'm confident this won't be the last you hear from Security on improvements in this regard.

Sure. My point was that it's very rare to ask users to do a password change, so unless you first do what you can to ensure that they'll select good passwords, it's a missed opportunity: if everyone changes their password now and additional checks get implemented next year, most of those admins won't change their password for another ten years so it won't have much effect on them. But I guess that horse already bolted since the mass messages asking for password change already went out.

On the topic of communication, one thing I've learned from this is to perhaps share early plans and ideas with other WMF staff not necessarily on the team that is actively involved in this topic area. You've given some great advice and I appreciate it.

That's generally a best practice IMO (also in line with movement values), even outside staff as long as it's a trusted place (e.g. the functionaries mailing list).

But I agree that as we have multiple requirements, easily seeing them all at once could be helpful.

Well, most of our requirements are not really worth stating. "Your password should not be popular" or "Your password cannot match the blacklist" is not really useful for the user unless it's explaining a problem with a password they already entered. The minimum length is probably the only one that's worth stating in advance (the only other actionable one is "should not match the username" but that's probably trivial enough that it's enough to point out in the very rare cases where someone does that).

the iOS app shows a temporary password error (probably from password reset):

The API response for login with a temporary password (that you get during password reset) and login with a normal password that MediaWiki then asks you to change is somewhat similar, so apparently the app confuses them. T157517 seems to be the (old) task about that.
I guess that's not too bad, the message is confusing but at least the user does get a password change prompt.

I do not have an Android device to test.

I don't want to mess with my password to test it, but just from looking at the code, it seems it has the exact same logic: if the response is a password form, it assumes the user is doing a password reset.

And if these users are not permissioned, then there will be no interruption at all.

Indeed. "Real" bots usually aren't (or so one would hope), but for assisted editing tools it is not so rare: AWB uses the account of the owner, and Pywikibot is usually configured with both the bot account and the owner account, and it switches to the owner account for tasks it needs an admin flag for.

TBolliger renamed this task from Change password length requirement and ensure enforcement to Change password length requirement and ensure enforcement for privileged users (from 8 to 10).Dec 10 2018, 7:51 PM
TBolliger updated the task description. (Show Details)

Change 478806 had a related patch set uploaded (by Dmaza; owner: Dmaza):
[mediawiki/core@master] Increase default minimum password length on multiple groups

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

Change 478807 had a related patch set uploaded (by Dmaza; owner: Dmaza):
[operations/mediawiki-config@master] Increase default minimum password length on multiple group

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

Change 478806 merged by jenkins-bot:
[mediawiki/core@master] Increase default minimum password length on privileged groups and bots

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

Change 478807 merged by jenkins-bot:
[operations/mediawiki-config@master] Increase default minimum new password length to 10 for privileged groups

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

Mentioned in SAL (#wikimedia-operations) [2018-12-13T23:57:14Z] <jforrester@deploy1001> Synchronized wmf-config/CommonSettings.php: T208246: Increase default minimum new password length to 10 for privileged groups (duration: 00m 44s)

Jdforrester-WMF added a subscriber: Jdforrester-WMF.

This is now live in production for privileged groups (in nag-mode for existing passwords, and enforcing for new passwords).

TBolliger closed this task as Resolved.Dec 14 2018, 12:01 AM
TBolliger moved this task from Review to Done on the Anti-Harassment (AHT Sprint 35) board.

Thank you James!

Change 479570 had a related patch set uploaded (by Jforrester; owner: Jforrester):
[operations/mediawiki-config@master] Enforce a 10-byte password for privileged users

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

Some possible fallout from this (T211952: Unable to log in) as Gergo mentioned might happen

Some possible fallout from this (T211952: Unable to log in) as Gergo mentioned might happen

Yeah, password change via a browser seems to have solved it. Made https://en.wikipedia.org/w/index.php?title=Wikipedia_talk:AutoWikiBrowser&oldid=873669051#Suddenly_getting_login_failed_error_messages? to try and remove some of the eventual phab tickets

Dunno if/how we can handle this error better client side if the api is giving something a bit vague

@Reedy Thanks for posting on the talk page. I hope that helps some folks figure out their issue if they run into it.

The workflow here isn't ideal. However, from a broader perspective, this is sort of what we wanted to happen, that is, for passwords to be "upgraded," right?

Reedy added a comment.Dec 14 2018, 5:18 PM

The workflow here isn't ideal. However, from a broader perspective, this is sort of what we wanted to happen, that is, for passwords to be "upgraded," right?

I think so. Ideally, we'd get a better error code/message from the API (I'm not sure how feasible this actually is), and then allow clients (like AutoWikiBrowser) to handle it differently, and display a more useful error message.

I don't think (at least in the case of AWB; mobile apps might be different depending on they handle it) it's necessary for all the apps to help the user do the password change or anything like that, just point them in the right place to get it sorted

Tgr added a comment.Dec 17 2018, 7:20 AM

Ideally, we'd get a better error code/message from the API (I'm not sure how feasible this actually is), and then allow clients (like AutoWikiBrowser) to handle it differently, and display a more useful error message.

There are three possible ways to handle this:

  • Tell the user that they need to change the password. There isn't really a good way to do this; AuthManager basically returns a form description (two password fields and a message that's probably generated from the password validation error) so either reliably identifying that situation or turning it into a single error message that makes sense to the user is not trivial.
  • Tell the user to go set up bot passwords. This is what the current error message does (I did not realize that when I wrote my original comment) and I think that is a pretty good way to handle it actually. Bot passwords mean future new authentication response types won't cause any problems, plus they are unguessable, plus you can restrict what rights you have when logging in via the bot password, so IMO promoting its usage is a good idea.
  • Implement action=clientlogin so the app can handle whatever the login form throws at it, without knowing in advance what it will be. That's not super hard but still not worth the effort IMO.
Tgr added a comment.Dec 17 2018, 7:29 AM

FWIW the current error message is

{
    "login": {
        "result": "Aborted",
        "reason": "Authentication requires user interaction, which is not supported by \"action=login\". To be able to login with \"action=login\", see [[Special:BotPasswords]]. To continue using main-account login, see \"[[Special:ApiHelp/clientlogin|action=clientlogin]]\"."
    }
}

so I think AWB's problem is that it displays result (which is meant to be the machine-readable field) and not reason.

Tgr added a comment.Jan 12 2019, 10:46 PM

Looks like we ended up with a 10 minlength for bots as well (via the MediaWiki core patch). Is that intentional? In Wikimedia config bots don't count as privileged, and they don't seem particularly dangerous (well, apart from T151408: Separate bot right for normal pages and interface (MediaWiki:) pages, which is fixable). The new password policy mentions bot admins, but I'm pretty sure that refers to the botadmin group (an obscure role used on some Asian and Middle-Eastern wikis), not bot. Is this really something that should live in MediaWiki core?

Looks like we ended up with a 10 minlength for bots as well (via the MediaWiki core patch). Is that intentional? In Wikimedia config bots don't count as privileged,

Is that so? According to https://en.wikipedia.org/wiki/Special:ListGroupRights , bot have a lot of extra privileges on English Wikipedia (as an example), including editsemiprotected, autopatrol, and ipblock-exempt, and exemptions from captchas and various rate limits.

and they don't seem particularly dangerous (well, apart from T151408: Separate bot right for normal pages and interface (MediaWiki:) pages, which is fixable).

I don't want to be too alarmist about it, but there are clearly certain types of attacks for which bot rights could come in very handy, for example the one demonstrated in this case.

The new password policy mentions bot admins, but I'm pretty sure that refers to the botadmin group (an obscure role used on some Asian and Middle-Eastern wikis), not bot. Is this really something that should live in MediaWiki core?

Tgr added a comment.Jan 14 2019, 6:32 AM

bot have a lot of extra privileges on English Wikipedia (as an example), including editsemiprotected, autopatrol, and ipblock-exempt, and exemptions from captchas and various rate limits.

None of those are particularly dangerous, and we don't consider other groups which have them privileged. (We don't even consider groups with editprotected / patrol privileged.) The ability to do bot-flagged edits is the only thing that makes bots interesting from a security perspective.

I don't want to be too alarmist about it, but there are clearly certain types of attacks for which bot rights could come in very handy, for example the one demonstrated in this case.

It would certainly make attacks more annoying, if that's were we want to draw the line. I guess we consider accounts with delete or block powers as privileged, and those are also more annoying than dangerous...

I'll check with @JBennett if the limit of 10 is indeed intended for bot accounts.

Tgr added a comment.Jan 14 2019, 7:40 PM

On a closer look (which I should have done before raising here, sorry) bots had a minlength of 8 in core for a long time, and all that happened was that it was raised to 10 in rMWfc9efe67d599: Increase default minimum password length on privileged groups and bots at the same time when all the other core minlength settings were raised. Which certainly makes sense, it keeps things simple. So please disregard the above.

Change 479570 had a related patch set uploaded (by Jforrester; owner: Jforrester):
[operations/mediawiki-config@master] Enforce a 10-byte password for privileged users

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