Allow admins to generate and send new passwords for users

Description

For sites that have a lot of user accounts (such as community forums), it'd be really nice for admins to be able to manually generate a new password for user accounts and then automatically send that new password via email. The option to flag the user's account so they are encouraged to reset their password (exactly as they are when using an auto-generated password) would be excellent.

Also seems like this would be a useful addition to the password reset screen, as suggested in ​IRC. In that case the password would need to be visible so the user can record it since it won't be emailed.

This probably deserves a separate ticket: Plaintext email is inherently insecure, so when passwords *are* emailed, we should force users to reset their password on the next login.

Send this password to the user by email.
Encourage the user to change their password, once logged in.

A global set of options would prevent having to check the boxes for each and every user, and instead allow this to be set as a global policy if desired.

A required password length, and format requiring such items as an uppercase letter and a number, etc., should also be available as a global option.

Perhaps a new submenu under Settings could be added, like Security, where these options would be available, and where plugins could add more options that could be applied to other areas like the new WP-API from Ryan McCue.

This ticket was mentioned in IRC in #wordpress-dev by nacin. ​View the logs.

There is a need for a global settings panel in multisite networks and also, where sites require greater security, an additional option to force users to change their password, once they've logged in for the first time.

I think passwords should not be sent via email at all. Send a link to the password reset form, as when the lost password form is used.

At least passwords should no be sent from sites with a secure admin (https).

If WordPress has sent a password via email there should be a nag, at least, as when the initial password is not changed yet. This is not very user friendly since the user must use two passwords, first the generated one and then the changed one.

And a nag that is just ignored for long time doesn't make the password invalid.

Emails can be intercepted, as can http. But emails are usually stored for years, and if they are exposed by accident, an old password may still be valid. One may argue that if an email client is exposed or an account is hacked, then a wrong person may change the password. Such change may be detected by the owner and legitimately changed. But a leaked, working password is worse, since no one might even get suspicious.

But enhancement proposed in this ticket will make WordPress a little bit easy to use, especially for the admin, but far from more secure, and a bit less user friendly for the non-admin (being nagged instead of changing the password once and securely).

The existence of the nag itself indicates that sending passwords via email is not regarded a secure practice.

I think passwords should not be sent via email at all. Send a link to the password reset form, as when the lost password form is used.

At least passwords should no be sent from sites with a secure admin (https).

If WordPress has sent a password via email there should be a nag, at least, as when the initial password is not changed yet. This is not very user friendly since the user must use two passwords, first the generated one and then the changed one.

And a nag that is just ignored for long time doesn't make the password invalid.

Was talking about this today at BeachPress and just bouncing ideas. One thing that sounded better from a security standpoint was to flag the account and force a reset.

Most of the plugins, and the manual way to do it is just reset the password for the user but not send via email. That way they need to request a password reset so they get the link to reset it themselves. Downside is that in theory they can just reset their new password to the same as the old password.

If we added a user meta flag that their account was locked or due for a password reset, we could compare the hash of the new password to what's currently in the database and force them to set a different password.

I also like the eye icon, however i'm wondering about compatibility with password helper plugins - specifically, I use lastpass and it puts a background image into password fields in just the spot you indicated for the 'eye' icon:

How about placing the eye icon just to the right of the form field? we have nice dashicon we can use (visibility):

In 24633.11.patch​ - use dashicon for show/hide password instead of text strings; first pass, I attempted to add some color indication of the status; (black/gray); placed icon outside field to avoid conflicts with lastpass.

adding some space to the right of the icon might help connect it more to the input on its left. i also liked the original idea of putting the eye inside the field (pretty straightforward with css) - but found it directly conflicted with the icon (and click handler) lastpass placed there - see cl.ly/image/2U0D2H2A390b. we should be able to tell lastpass to skip these fields by setting autocomplete="off" for the form (see ​http://stackoverflow.com/questions/20954944/stop-lastpass-filling-out-a-form). you could still use lastpass, just not from the form fields.

we should be able to tell lastpass to skip these fields by setting autocomplete="off" for the form

I don't love that idea. As a LastPass user, I definitely prefer to generate passwords using LastPass rather than WordPress, partially because I can share it to another LastPass user without using E-Mail, and partially because I can control how long and complex it is.

we should be able to tell lastpass to skip these fields by setting autocomplete="off" for the form

I don't love that idea. As a LastPass user, I definitely prefer to generate passwords using LastPass rather than WordPress, partially because I can share it to another LastPass user without using E-Mail, and partially because I can control how long and complex it is.

I hear ya! I'm also a lastpass fan and would rather not disable it - although I would note that you can still use if with the autofill turned off on these fields, you would have to use the extension/add on icon to activate the generate password feature.

what about if lastpass was active, putting the eye/visibility icon a bit to the left or right of the lastpass icon (meaning you would have two icons in the field - is that too weird? or put it outside the field if lastpass active, inside otherwise?

we should be able to tell lastpass to skip these fields by setting autocomplete="off" for the form

I don't love that idea. As a LastPass user, I definitely prefer to generate passwords using LastPass rather than WordPress, partially because I can share it to another LastPass user without using E-Mail, and partially because I can control how long and complex it is.

I hear ya! I'm also a lastpass fan and would rather not disable it - although I would note that you can still use if with the autofill turned off on these fields, you would have to use the extension/add on icon to activate the generate password feature.

what about if lastpass was active, putting the eye/visibility icon a bit to the left or right of the lastpass icon (meaning you would have two icons in the field - is that too weird? or put it outside the field if lastpass active, inside otherwise?

Putting in a specific rule for lastpass seems like a slippery slope to me. What about when a new password management app comes along and it also adds an icon? And then another? I'd rather see a generic setup that can work with any app.

Putting in a specific rule for lastpass seems like a slippery slope to me. What about when a new password management app comes along and it also adds an icon? And then another? I'd rather see a generic setup that can work with any app.

+1 for a generic approach. Obviously it would nice to work nicely with LastPass, but we shouldn't specifically tailor it for LastPass compatibility.

Putting in a specific rule for lastpass seems like a slippery slope to me. What about when a new password management app comes along and it also adds an icon? And then another? I'd rather see a generic setup that can work with any app.

+1 for a generic approach. Obviously it would nice to work nicely with LastPass, but we shouldn't specifically tailor it for LastPass compatibility.

Ok, since lastpass already has this spot, lets stick with the 'right of the field' position and add some more space to the right of the icon to better tie the icon to the field.

It looks near perfect, but in the JS console the following appears:JQMIGRATE: Can't change the 'type' of an input or button in IE 6/7/8

What about IE 6/7/8 support, do we need to fix this? I'm on a Mac, somebody on Win could try it with ​IETester ?

I think it looks cluttered, and I'm not really sure why the icon is by itself like that. The padding on the right looks odd. And where else in the admin do we have a standalone icon that's clickable. I feel if we're going to keep it, we should just put in a button and remove the padding to right of it.

Annnnnnnd this is coming together too late for 4.0 -- we're almost in beta 2, afterall.

And yes, I realize the frustration punting this will cause. It's been marked as a task since 3.7 but we still don't have the UI nailed down, and this should really get some feedback from the UI team and/or user testing before any hard decisions are made.

Let's keep working on this and see if we can't get it in early in 4.1 :/

Annnnnnnd this is coming together too late for 4.0 -- we're almost in beta 2, afterall.

And yes, I realize the frustration punting this will cause. It's been marked as a task since 3.7 but we still don't have the UI nailed down, and this should really get some feedback from the UI team and/or user testing before any hard decisions are made.

Let's keep working on this and see if we can't get it in early in 4.1 :/

Could it be milestoned for 4.1 at least to help encourage people to look at it?

Looks like there's a little weirdness with the interaction after generating a password with 24633.16.patch​.

I ran through four common scenarios (imo), and my general conclusion is that we should at the very least always show both fields and the strength meter whenever the first field is interacted with, whether that be by clicking the button, pasting something in, typing something in, or clicking the generate button after some text has already been entered in one or both of the fields. Or just show all three elements all the time.

Here are the results of the four scenarios:

1. Clicking the Generate Password button:

The password is generated and sent to the password field

The password is visible

The second password field and strength meter don't appear

If you select or otherwise interact with the generated password, the second password field and strength meter suddenly show up and both fields mask the password

24633.17.patch is an updated patch that makes the fields visible at all times.

It still feels a little "off" to me so I'd love to hear some feedback on this altered version. The main issue I see still is that if you generate a password, it's shown in plaintext but then gets masked if you click into the field and type CMD/CTL+C to copy it. I feel it should stay as plain text if copying it to the clipboard.

Change from 24633.17.patch - change passwords fields back from text to password on blur instead of keyup. Fixes an issue in firefox where hitting ctrl/cmd-c to copy also changed the field back to password (masked)

How about logging the password change datetime and possibly password strength (and other data over time) so that if somebody wanted to implement a password changing policy, site-wide, they would have that information to hand. i.e. notify users who haven't changed password in 120 days etc.

I had a chance to chat with Pippin (@mordauk) about this a little bit last week and I think we both agree that this task may be best served by approaching the password generation functionality as something that should be developed in a standalone way.

The thinking is that if we abstract out the password generation functionality, we can design it in such a way that it could easily be reused in several different areas of core. For the sake of completeness, I envision those areas would include:

As for the interaction stuff related to sending passwords to a user and/or recommending they change passwords on first login, I think those should be handled separately. If we really want to have a win here, we need something stable and reusable.

To that end, I'm not sure that necessarily supporting things like Lastpass and all the UI things that come along with it would be necessary to get to a minimum viable product. We'd also probably want to consider whether the password meter UI would be useful in these other contexts as well, but that's probably also a separate ticket.

Next Steps

I think the next step here would be to take the latest patch and break out the generation code to a point where you could simply point it at a group of selectors, e.g. button, first password, second password, and it would just work.

On top of that, we need to be cognizant of the mobile and accessibility implications that come along with the introduction of any kind of new core UI, so getting a consult from those teams would be a good step too.

There's some work yet to do here, but I think we could really get a great feature out of this.

24633.23.patch is my first pass at creating an abstracted password generation API that will make it much simpler to add password generation to profiles, user registration, user creation, etc.

To set up password generation, we can call the new passwords object like so:

passwords.init( '#pass1', '#pass2', '#generate-password' );

The first password, confirmation, and submit field selectors are passed as parameters to the function, which will then handle generating the password, checking the strength, and displaying the results.

24633.23.patch is my first pass at creating an abstracted password generation API that will make it much simpler to add password generation to profiles, user registration, user creation, etc.

To set up password generation, we can call the new passwords object like so:

passwords.init( '#pass1', '#pass2', '#generate-password' );

The first password, confirmation, and submit field selectors are passed as parameters to the function, which will then handle generating the password, checking the strength, and displaying the results.

Wondering if should namespace into wp global to make object wp.passwords? Also, maybe move to wp-util instead of user-profile.js? Will plugins/themes be able to leverage the password generator?

Namespacing it sounds good. However moving it to wp-util.js doesn't seem right. Currently user-profile.js requires password-strength-meter.js which loads zxcvbn.min.js which is a 683KB minified JS file. There is no way we are going to load that "globally" :)

Perhaps better to add the password checking/generating functions to wp.passwordStrength in password-strength-meter.js? Then we can enqueue that file everywhere a password can be typed. I know the names aren't that good. We could probably rename the file, but should keep the script-loader "handle" name for back-compat.

Perhaps better to add the password checking/generating functions to wp.passwordStrength in password-strength-meter.js? Then we can enqueue that file everywhere a password can be typed. I know the names aren't that good. We could probably rename the file, but should keep the script-loader "handle" name for back-compat.

24633.27.patch refreshes the patch so it applies cleanly. It also sets the width of the #generate-password input on user-new.php to auto. Without setting the width to auto, the submit button gets set to 25em, the same width as the input fields. To be consistent with user-edit.php, the width should be automatic based on the text length.

As the above, I've tried to come up with an integrated concept, trying to balance in a single solution all the issues discussed above. Here's attached above the "Universal Overlay" concept:

The UI is designed as a modular component: abstract from its context, but with a visual design that fits in every (hopefully) WordPress context. In the above you see it used both in wp-admin and in the login page (note that the width stretches to match the text-field, so it's designed to fit the smaller of the two).

The field starts blank, so as a user you don't have to read information that you need only when you start typing. The idea is to have the clean field, that expands with the overlay and the password hint once it gets focused. This introduces some moving of the fields around, which is not ideal, but I feel the benefits outbalance that slight movement.

By default we use "Visible", so there's just one field. Better to avoid mis-typing frustration, and avoids using a negative-for-positive meaning UI ("check to hide" vs "check to show").

If "Visible" gets unchecked we animate the second verification line in (fold-open animation), empty.

Visible and Generate go hand by hand: clicking generate turns on automatically the visibility, and un-checking then the visibility checkbox shows the verification field empty, so you have to type the generated password to make it validate.

If JavaScript is off we still get a single field that works (with a visible password), so it's still functional.

The strength indicator uses the padlock icon to reinforce the security theme (I know, this sounds silly, but there are studies showing that the icon of a padlock helps perceiving a form more secure).

That's all I came up with. I feel it's a good direction, even if maybe there are some details that need more fine-tuning. :)

Will the various types of colour blindness be able to distinguish between the green padlocks and the grey padlock?

The field starts blank, so as a user you don't have to read information that you need only when you start typing.

The UX then means a user has to focus in the field just to get the Generate button appear before they can click it, and that's one step too many and more confusing for non-visual users. Could the Generate button always be shown, and only have the password strength indicator be shown when the field is not empty, not even just on focus, as per the previous screenshots in this ticket? They are two separate tasks - generation of a password, and analysis of a password.

As a general side note for some of the other screenshots - screen reader users should probably be given some clue that the Generate button exists, before or as they focus on the password field.

Will the various types of colour blindness be able to distinguish between the green padlocks and the grey padlock?

Sure. A color combination that is distinguishable is doable.
The text will still give that information regardless. :)

The UX then means a user has to focus in the field just to get the Generate button appear before they can click it, and that's one step too many and more confusing for non-visual users.

There should be no issue there: the form could easily pop up on tabbing as any normal hidden field like the "Skip to content" field do, thus being accessible, and would be an experience functionally identical to someone clicking on the text-field (the reader would read "Change Password" and then access the fields in sequence). But I'm sure there are other techniques that could be used too.

Having to click into the text field, before the Generate button becomes available. That's like having to put the car key in the lock before one can open it remotely with the fob. The initial step is redundant. Make the Generate button always be available, not just on text field focus.

Having the Generate button after the field means a screen reader may have an experience of:

Read the Change Password label.

Navigate to the corresponding field and focus it.

Manually enter a made-up password.

Navigate to the next item (which may be the Generate button).

Realise that the Generate button exists, and that they didn't need to make up a password manually.

Having the button before (in the source) and/or use of aria-* attributes to describe the password field to indicate that the button exists, should help mitigate that.

Likewise, having the strength indicator before just seems odd to me. It's appearance is in response to the password field being empty, so why have it visually appear before the field? Imagine if the comment preview here in Trac appeared above the Add Comment field. From an accessibility point of view, aria-live should help screen reader users, so the placement is a little less important for them.

Yes (1) and (3) are choices made in this design suggestion. I feel the overall balance of it works well, but sure, it's just a choice out of many. I don't think there's a clear winner here: you either compromize cleanliness, flow, legibility or overall hierarchy. In this scenario I make explicit choices in one direction, which I feel works best, but yes, it's a choice. :)

Regarding (2), I don't think it's an issue since the DOM could be arranged in a way that makes it properly ordered, having the "Generate" button come first (i.e. having the box before the field, or other technical solutions).

Right; because we built on the work started here, I thought this ticket was resolved. I can see how adding the 'send reset link' button would improve what we have here.

Thanks for your code, thats most of the work to get a patch! I am a little hesitant to re-open this ticket, mostly because it has 104 comments already! Would you be willing to create a new ticket to cover this specific feature?

I will happily work on converting your plugin code into a core patch, seems like a good idea! Would make a nice bulk action for the user screen as well for a quick way to reset a bunch of user passwords.

If the section was extendable (like I didn't have to make a new 'mischief' section in the profile) a plugin would work fine for the long run, but being able to just send folks a password reset link will help support a ton.