Add change-password nag for auto-generated passwords

[DD32]

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.

[westi]

This is just cute!

Coming to a trunk install near you soon

[DD32]

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..

[westi]

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

[westi]

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

[demetris]

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

[demetris]

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

[westi]

Looks like Andrew did it in [11165]

[TobiasBg]

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.

[DD32]

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.

[DD32]

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.

[ryan]

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

[demetris]

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

2. 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!

[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... :)

2. 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.

[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.

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.

[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. :-)

[demetris]

@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... :)

2. 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.

[hakre]

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-Bernardy]

Change the notice message to remove inconsistencies

[Denis-de-Bernardy]

uploaded a patch to change the nag message

[ryan]

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

[demetris]

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.

[Denis-de-Bernardy]

@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

[dd32]

@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.

[demetris]

@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).