WordPress.org

Make WordPress Core

Opened 2 years ago

Last modified 15 months ago

#35817 new enhancement

Force users to set strong passwords

Reported by: ericlewis Owned by:
Milestone: Awaiting Review Priority: normal
Severity: normal Version:
Component: Administration Keywords: 2nd-opinion
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 (18)

#1 follow-up: @Clorith
2 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
2 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
23 months 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
23 months 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
23 months 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.


23 months ago

#7 @Presskopp
23 months 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
23 months 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
23 months 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
23 months 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
23 months 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
22 months 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
22 months 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
15 months ago

#40234 was marked as a duplicate.

#15 @jrchamp
15 months 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
15 months 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
15 months 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
15 months 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.

Note: See TracTickets for help on using tickets.