WordPress.org

Make WordPress Core

Opened 5 years ago

Closed 5 years ago

Last modified 5 years ago

#9710 closed enhancement (fixed)

Add change-password nag for auto-generated passwords

Reported by: DD32 Owned by: westi
Milestone: 2.8 Priority: normal
Severity: normal Version: 2.8
Component: Administration Keywords: has-patch commit
Focuses: Cc:

Description

The attached patch adds a "Change Password" nag, Basically, When someone logs in with a auto-generated password (Fresh install, Or password reset) they're greeted with a message asking if they'd like to change their password.

My reasoning for this? I always forget to change my password after setting up a new install..

The dialogue contains a dismiss option, which is handled by the User Settings JavaScript functionality (which eventually updates the user meta). The dismiss option also has a non-js fallback.

It may need testing, but seems to work nicely for me. It'll need some rewording perhaps.

Attachments (5)

9710.diff (3.5 KB) - added by DD32 5 years ago.
common.dev-r11162.yuic-242.js (6.5 KB) - added by demetris 5 years ago.
common.dev.js at r11162 compressed with YUI Compressor 2.4.2 (default options)
9710.2.diff (1.4 KB) - added by DD32 5 years ago.
9710.3.diff (1.4 KB) - added by DD32 5 years ago.
9710.4.diff (859 bytes) - added by Denis-de-Bernardy 5 years ago.
Change the notice message to remove inconsistencies

Download all attachments as: .zip

Change History (29)

DD325 years ago

comment:1 westi5 years ago

  • Keywords needs-testing added; 2nd-opinion removed
  • Milestone changed from Future Release to 2.8
  • Owner set to westi
  • Status changed from new to assigned

This is just cute!

Coming to a trunk install near you soon

comment:2 DD325 years ago

An after thought was that default_password_nag_handler() should probably check the usermeta first before using get_user_setting(), It'll probably be better at short circuiting the function..

comment:3 westi5 years ago

(In [11162]) Add a nag message if the user is still using an auto-generated password. See #9710 props DD32.

comment:4 westi5 years ago

  • Cc azzozz added
  • Keywords has-patch needs-testing removed

The new js needs minifying and I couldn't get YUI to work :-(

demetris5 years ago

common.dev.js at r11162 compressed with YUI Compressor 2.4.2 (default options)

comment:5 demetris5 years ago

Attached a yui-compressorified version of common.dev.js. :-)

comment:6 westi5 years ago

  • Resolution set to fixed
  • Status changed from assigned to closed

Looks like Andrew did it in [11165]

comment:7 TobiasBg5 years ago

  • Resolution fixed deleted
  • Status changed from closed to reopened

Shouldn't the nag screen also go away, after I change the password from the auto-generated one to my own?

I just installed the latest trunk and it didn't. (It only disappeared after explicitly clicking the dismiss link.)

Because otherwise the message is just no longer true.

comment:8 jhodgdon5 years ago

  • Component changed from Accessibility to Warnings/Notices

comment:9 DD325 years ago

  • Component changed from Warnings/Notices to Administration

Indeed it should disappear after a manual password change.

Looks like i left that branch out of my patch.

New users that are created from the admin panel also do not gain the password-nag, IMO, The password form on the new-user needs a "Assign user a random password value" which would tie into this functionality..

Might also need to check if the user has permission to modify his/her profile/password, I'm not sure what hooks/caps exist to limit that, but probably should be checked as well.

DD325 years ago

DD325 years ago

comment:10 DD325 years ago

attachment 9710.2.diff added

  • No.. That sucks way too much. Too hacky.

attachment 9710.3.diff added

  • Thats better.
  • Upon password changing, It disables the nag.
  • Short circuits the functions if the usermeta has been updated already.

comment:11 ryan5 years ago

  • Resolution set to fixed
  • Status changed from reopened to closed

(In [11217]) Default password nag fixes. Props DD32. fixes #9710

comment:12 demetris5 years ago

  • Keywords 2nd-opinion added
  • Resolution fixed deleted
  • Status changed from closed to reopened

I think this patch is a bad idea.

First WordPress says:

— (strong)(em)Note that password(/em)(/strong) carefully! It is a (em)random(/em) password that was generated just for you.

Then, on the next screen:

— Hey, that password I made *just* for you is not easy to remember! Change it now!

Then, on Your Profile:

— You should be using a long password with mixed-case letters, numbers, and special characters.

:-D

So, the present patch:

  1. Introduces inconsistency
  1. Gives bad advice (I think)

In any case, I have not seen any end user complaining about the random password. (And, even if end users did complain, random passwords are used for a reason.)

Thanks for reading!

comment:13 demetris5 years ago

  • Cc dkikizas@… added

comment:14 follow-up: DD325 years ago

  1. Introduces inconsistency

Point taken, Lets change the installer's notice to "Take note of this, You'll need it to login in the next step, After which you may change this password to something easier to remember if you choose"

I'd also be for the installer's page with the password with an auto-login button myself... :)

  1. Gives bad advice (I think)

Yes, Random passwords are good. But who really leaves them as random? Theres nothing stoping them from leaving it as random, its a simple click. The majority of users will want to change their passwords for future logging in.

comment:15 follow-up: hakre5 years ago

A reason to change the initial password is, because it was unsecurely transfered via email. because of that it makes sense to change the password. and because of that, the hint to change the default password makes sense.

the security can be increased further by proecting the backend with ssl connections for example. but that would be a notice worth for the admin.

comment:16 in reply to: ↑ 15 ; follow-up: Denis-de-Bernardy5 years ago

Replying to hakre:

A reason to change the initial password is, because it was unsecurely transfered via email. because of that it makes sense to change the password. and because of that, the hint to change the default password makes sense.

and then, the user sets it over an insecure connection... it's just a blog, it's not a bank account. :-)

comment:17 in reply to: ↑ 14 demetris5 years ago

@hakre: That’s a different story, and if it’s a problem to look into, it’s not solved by this patch.

Replying to DD32:

  1. Introduces inconsistency

Point taken, Lets change the installer's notice to "Take note of this, You'll need it to login in the next step, After which you may change this password to something easier to remember if you choose"

I'd also be for the installer's page with the password with an auto-login button myself... :)

  1. Gives bad advice (I think)

Yes, Random passwords are good. But who really leaves them as random? Theres nothing stoping them from leaving it as random, its a simple click. The majority of users will want to change their passwords for future logging in.

I disagree! :-)

WordPress is trusted by its users, probably more so than other applications its users rely on, and I believe that it should try to put this trust to good use and try to set a good example.

This patch nullifies the good example WordPress sets on installation only to try to solve a problem that does not exist in typical WP usage.

comment:18 in reply to: ↑ 16 hakre5 years ago

Replying to Denis-de-Bernardy:

Replying to hakre:

A reason to change the initial password is, because it was unsecurely transfered via email. because of that it makes sense to change the password. and because of that, the hint to change the default password makes sense.

and then, the user sets it over an insecure connection... it's just a blog, it's not a bank account. :-)

some blogs use SSL in the backend. and i named that. user data always should be handeled as secure as possible (even not done on every wp-blog, i know, but we should enable users to do so). so i have no problems to offer features to wordpress users (wordpress users =/= some wordpress blogs user accounts).

Denis-de-Bernardy5 years ago

Change the notice message to remove inconsistencies

comment:19 Denis-de-Bernardy5 years ago

  • Keywords has-patch commit added; 2nd-opinion removed

uploaded a patch to change the nag message

comment:20 ryan5 years ago

  • Resolution set to fixed
  • Status changed from reopened to closed

(In [11266]) Update password nage text. Props Denis-de-Bernardy. fixes #9710

comment:21 demetris5 years ago

I will not reopen this but I just want to say that I still disagree, even with the message as toned down by Denis.

The inconsistency is still there:

On one screen WP recommends (implicitly, by making a random password for the user) security over convenience.

On the next screen it suggests the way of convenience over the way of security.

I believe WP should be able to send a simple and clear message at least at this basic level (and before we go into finer UI points which are objectively difficult to get right).

Also, very importantly, this modification is based on the experience of the wrong people. I think I can understand DD32’s inconvenience. I have about 10 test WP installs myself and the random passwords are an inconvenience for me too. For my test installs, I would be happy if WP offered me an option right from the start: Blank password. :-D

But that’s not typical usage. Although I don’t have any stats, I feel safe in saying that the typical usage is closer to the other end:

One user, one WP install, interfacing by means of one or two clients (which are pretty good at managing passwords, random or not, anyway).

And this usage, as far as I know, does not give rise to any complaints that would justify modifications in this part of WP.

I’ll shut up now.

comment:22 Denis-de-Bernardy5 years ago

@demetris -- try this shell script (edit the db name as needed):

#!/bin/bash
#

if [[ $# == 2 ]];
then
	db=$1
	sql=$2
elif [[ $# == 1 ]];
then
	db=sem
	sql=$1
elif [[ $# == 0 ]];
then
	db=sem
	sql=
else
	echo 'Usage: sem [db_name] [sql_dump]'
	exit -1
fi

mysql -u root -t <<SQL
DROP DATABASE IF EXISTS $db;
CREATE DATABASE $db;
SQL


if [[ "$sql" != '' ]];
then
	mysql sem -u root < $sql

	mysql sem -u root -t <<SQL
UPDATE	wp_users
SET		user_login = 'admin',
		user_pass = md5('admin')
ORDER BY ID
LIMIT 1
SQL

	#statements
fi

echo 'DB reset complete'

reset db:

sem_db

reset using an sql dump:

sem_db dbdump.sql

comment:23 follow-up: dd325 years ago

@demetris: You're right that my use-case is a rare one. However, Users signing up to a wordpress install and recieving a random password IS a common scenario, Sure, most of us have closed installsm but there are a fair few that allow signups.

Random passwords are just as secure as a decent password, 'abc123' is not a decent password. Nor is quite a lot of passwords the majority of us use, but hey, We all change random passwords to those which we can remember better. Some of us like security, and generally will make sure that our passwords cannot be guessed easily.. Thats our choice - to make a secure password. Theres nothing stoping someone choosing that and with an extra mouse-click, dismissing the dialogue - They dont loose any time, nor does it add a high user-overhead.

Personally i'd have also suggested a choice during install to either set a random password or one of my own choosing (without adding files... or using a 3rd-party installer) - But i'm sure there'll be some who would be against that as well.

Worried about security? Set a decnet password (Longer than the random one auto-created, And while you're at it, Delete the admin account and create a new user. If you want simplicity and ease of use for all users, then in my opinion, This is just one of the few parts that make the UI nicer to use.

comment:24 in reply to: ↑ 23 demetris5 years ago

@Denis. Haha! Thanks! I don’t understand every bit of it but I think I get what it does. I’ll try it.

Replying to dd32:

@demetris: [SNIP]

Personally i'd have also suggested a choice during install to either set a random password or one of my own choosing (without adding files... or using a 3rd-party installer) - But i'm sure there'll be some who would be against that as well.

I think this would be the best way. Something like:

Password: [INPUT/TEXT: Type a password] [INPUT/BUTTON: Generate random]

Along with a check to not accept passwords that don’t meet certain requirements.

Because, now, whatever we do and whichever way we choose to formulate the new message, the fact remains that WP sends mixed signals: first it recommends implicitly one thing, then it suggests explicitly another.

This should not be happening.

WP is supposed to know better than its average user what the ideal is here and what the realistic expectations are, and it should try to strike a balance between the two and present the user with a simple and sensible solution (without dumbing anything down, of course).

Note: See TracTickets for help on using tickets.