Make WordPress Core

Opened 8 years ago

Last modified 6 weeks ago

#35817 new enhancement

Force users to set strong passwords

Reported by: ericlewis's profile ericlewis Owned by:
Milestone: Awaiting Review Priority: normal
Severity: normal Version:
Component: Login and Registration Keywords: 2nd-opinion close
Focuses: ui Cc:

Description

WordPress 4.3 added zxcvbn for better password strength testing.

The UI was also modified to push users to set strong passwords in various ways.

  • When setting a password, a strong one is generated for the user.
  • A user must check off an "Are You Sure?" checkbox to set a weak password.

This is great. However, an "Are You Sure" checkbox is what stands between an easily hackable WordPress site and an exponentially stronger WordPress site.

I would like to force users to set strong passwords in the UI.

Change History (23)

#1 follow-up: @Clorith
8 years ago

Although I am a fan of strong passwords, I also fear that this will lead to a rapid increase in repeated password recovery requests from Average Joe.

It's fine for those of us who are more than the casual computer user, with our password managers and such, but for grandma with her blog about home made meals, this might just be one of those "it's too complicated, I won't bother" situations, or they'll try it out and after the 7th password recovery in a week, they've had enough.

The current approach of providing a strong password, but letting the user go with one they created them selves and having to forcibly click a box confirming they are aware of the dangers is nice in that regard.

#2 @tw2113
8 years ago

As one who has many local dev sites, it's nice not absolutely having to have a strong password for my own private areas or with test users that I'm setting up for various purposes.

#3 @lovingboth
8 years ago

I'd like 'lowest acceptable password strength' to be an option in the Settings menus.

With the default set to 'nothing weaker than medium', but settable to 'yeah, "password" is ok' aka 'very weak' if that's what the admin wants.

#4 follow-up: @Presskopp
8 years ago

I think the solution as it is now beats the forcing someone into something. If you need to confirm a weak password, there is a chance to make you think of if this is really a good idea. If grandma wants 'Daisy0105' and the system responds with "Error: You are forced to use "?$hZF{hellofapasswordRL#Q#W" or something, because we say so", grandma will hate it.

#5 in reply to: ↑ 4 @ericlewis
8 years ago

Replying to Presskopp:

If grandma wants 'Daisy0105' and the system responds with "Error: You are forced to use "?$hZF{hellofapasswordRL#Q#W" or something, because we say so", grandma will hate it.

I would prefer we not deal in stereotypes like "grandma." My mother is a grandmother. She is internet literate and employs a system to manage her strong passwords, which she understands are important for user security and privacy.

Allowing users to easily enter weak passwords makes a WordPress site an easy target for hacker groups. Brute force user login attacks happen. I recognize this would implicitly force a lot of users to learn how to manage a strong password. I think this is good, and as a popular content management system for digital publishing we will be pushing forward internet literacy.

We could do something for developers to allow weak passwords for dev sites. Alternatively developers could also figure out how to manage strong passwords at scale.

This ticket was mentioned in Slack in #core by eric. View the logs.


8 years ago

#7 @Presskopp
8 years ago

I would prefer we not deal in stereotypes like "grandma."

Sorry, I didn't start! This is possibly going to be a bigger discussion about security principles. We could set a (not yet existing) variable in wp-config, say 'localusage = 1' to disable demand for strong passwords locally (and maybe more stuff like unlimited login time) or anything similar, like mentioned above.
I like strong passwords, but educating and forcing people should be used wisely.

#8 in reply to: ↑ 1 @SergeyBiryukov
8 years ago

Replying to Clorith:

The current approach of providing a strong password, but letting the user go with one they created them selves and having to forcibly click a box confirming they are aware of the dangers is nice in that regard.

I tend to agree. Personally, I use strong passwords even for development installs, but I've seen some sentiments on support forums that even the current "The password should be at least twelve characters long" phrase scares an average user and leaves an impression that the software is trying to outsmart them.

#9 follow-up: @lovingboth
8 years ago

Anyone who is an admin would be able to set the lowest acceptable password strength to whatever they like, via a simple dropdown / radio button menu in settings.

Anyone who is NOT an admin should not get to choose what the lowest acceptable password strength is, 'please confirm you want to use a rubbish password' prompt or not.

Only those who would like to financially guarantee that there won't be another user privilege escalation exploit (and there have been rather too many of those over the years) should be allowed to disagree with that.

I'm aware that there are plugins that offer this sort of thing, but as with brute force protection, this is something that should be in core.

#10 follow-ups: @ericlewis
8 years ago

We had a nice chat about this in #core today.

Some of the take-aways:

  • If we required strong passwords, users would probably do the least minimum change to their weak password to meet the rule. eg. instead of june2286 I might use june2286! and perhaps reuse this password across different websites.
  • It would be useful to know what causes more problems: weak passwords or password reuse.
  • This may or may not align with project goals.

#11 in reply to: ↑ 10 @lovingboth
8 years ago

Replying to ericlewis:

We had a nice chat about this in #core today.

I will have a look when I can do audio rather than text but..

  • If we required strong passwords, users would probably do the least minimum change to their weak password to meet the rule.

Quite possibly, but it should be up to the admin to decide what quality of password to require.

Plugins exist to do this, but as everyone knows, the takeup of them is a tiny fraction of installs. Do a search for 'password strength' in plugins and the first one has 1,000+ installs (and the third one, to stop WooCommerce doing it has 2,000+ installs!)

  • It would be useful to know what causes more problems: weak passwords or password reuse.

It would, but I'm not sure it's relevant to this feature request.

#12 in reply to: ↑ 10 ; follow-up: @ericlewis
8 years ago

Replying to ericlewis:

  • If we required strong passwords, users would probably do the least minimum change to their weak password to meet the rule. eg. instead of june2286 I might use june2286! and perhaps reuse this password across different websites.

I think this is okay. Stronger passwords are preferable to weak passwords.

  • This may or may not align with project goals.

I would say that security is a feature, and protecting sites from basic brute-force attacks make WordPress a better experience out-of-the-box.

#13 in reply to: ↑ 12 @lovingboth
8 years ago

Replying to ericlewis:

  • This may or may not align with project goals.

I hadn't realised that there are still people who prioritise 'user friendliness' over security as a project goal.

WordPress has gotten better about this, but it's been a long road and there's still some way to go before aspects aren't embarrassing. The result can be seen in the millions and millions of hacked WP sites out there.

Replying to ericlewis:

I would say that security is a feature, and protecting sites from basic brute-force attacks make WordPress a better experience out-of-the-box.

Yes. Other examples would be stopping attackers from trying as many username/password combos as they like before being slowed down, and removing the ability to do hundreds of them at a time from xmlrpc.php - see other tickets.

#14 @SergeyBiryukov
7 years ago

#40234 was marked as a duplicate.

#15 @jrchamp
7 years ago

Discussion from #40234: Would like the ability to require a minimum zxcvbn strength level.

Currently, any strength score that's not 3 or 4 shows the weak password information, but allows you to click a checkbox to ignore it and continue.

Additionally, zxcvbn has been updated in 4.8 and includes useful feedback information that can be displayed to the user.

#16 @jrchamp
7 years ago

  • Version 0.71 deleted

Version 0.71? Something seems wrong here and it won't let me fix it.

#17 in reply to: ↑ 9 ; follow-up: @robdxw
7 years ago

Replying to lovingboth:

Anyone who is an admin would be able to set the lowest acceptable password strength to whatever they like, via a simple dropdown / radio button menu in settings.

Anyone who is NOT an admin should not get to choose what the lowest acceptable password strength is, 'please confirm you want to use a rubbish password' prompt or not.

I tend to agree with this. By default, the current WordPress set up is: whoever sets the worst password controls how secure the site is. That seems fundamentally wrong - it should be the admin who controls how secure the site is, not anybody else. If the admin is happy for weak passwords to be in use, that's possibly a different matter, but they should at least have control over that decision.

(And apologies for the duplicate ticket - I did search first, but obviously not well enough).

#18 in reply to: ↑ 17 @lovingboth
7 years ago

Replying to robdxw:

Replying to lovingboth:

Anyone who is NOT an admin should not get to choose what the lowest acceptable password strength is, 'please confirm you want to use a rubbish password' prompt or not.

I tend to agree with this. By default, the current WordPress set up is: whoever sets the worst password controls how secure the site is. That seems fundamentally wrong - it should be the admin who controls how secure the site is, not anybody else. If the admin is happy for weak passwords to be in use, that's possibly a different matter, but they should at least have control over that decision.

Quite. Particularly given the 'at least one a year' user privilege escalation exploits that WordPress has had since the beginning.

See also https://core.trac.wordpress.org/ticket/37604 which is a request that the "Password Lost and Changed for user: [username]" emails to site owners contain WordPress's estimate of the strength of the new password.

#19 @peterwilsoncc
13 months ago

  • Component changed from Administration to Login and Registration
  • Keywords close added

I think the lack of progress on this ticket indicates enforcing password strengths in WordPress is unlikely to be implimented.

A part of the problem is that it's difficult to determine what is weak via algorithm alone. It's possible a false sense of security will be given to users by enforcing strong passwords that actually are not. For example, setting up an account with the username peterwilsoncc, I was able to remove the weak password warnings with the passwords Peter Wilson! and peterwilsonseasea, both of which a human would consider weak.

I suggest this ticket be closed and enforcing minimum strength passwords remain plugin territory.

#20 follow-up: @jrchamp
13 months ago

Systems should be "secure by default", not "secure when you install the right plugin". If you agree that Peter Wilson! is a weak password, then what we should be doing is increasing the baseline for what weak means. If we're using zxcvbn scores, then nothing should be less than 4/4. Ideally, we should take it one step further and use the guesses_log10 value instead and encourage people to choose something 15+ or 20+. This GitHub page makes those values visible: https://lowe.github.io/tryzxcvbn/

#21 @verygoode
3 months ago

Anecdotally, in my work with compromised sites across multiple hosts, weak and/or compromised passwords are the cause of compromised sites. Whether due to an admin's weak password or due to a privilege escalation via a weak password + another exploit.

This ticket was mentioned in Slack in #core by swissspidy. View the logs.


6 weeks ago

#23 in reply to: ↑ 20 @knofte
6 weeks ago

Replying to jrchamp:

Systems should be "secure by default", not "secure when you install the right plugin".

Totally agree with this. We manage some 100+ WP sites. The fact that we have to install a plugin to get a longer/more complex password than 12 characters for all the Administrators here is insane. Plugins are not a solution to every problem, and basic security Should be part of core for any application. DB already supports it, we just need the implementation for Admin to set min-required pass length.

Note: See TracTickets for help on using tickets.