Passwords in 4.3: Strong by Default

One of the development efforts in the WordPress 4.3 cycle was improving the way that passwords are chosen and changed. Before, people had to start from scratch when choosing a password. They were presented with an empty box, and had to use a really terrible tool for generating secure passwords: the human brain.

Here’s how things look now, as we approach 4.3’s release candidate…

Screen Shot

And when you click that button…

Screen Shot

You start out with a strong password. And if you like, you can just accept that. Most modern browsers will offer to remember it for you (as well as password managers like 1Password and LastPass). Or, you could go old school and write it on a sticky note. Hey: anything is better than choosing “letmein”!

You can, of course, click into the field and edit it. But now the password strength meter is better integrated with the field. Things start to look dire as you go your own way.

Screen Shot

That red seems to signal danger. And hey, look, below. This password is SO BAD that WordPress wants to make extra sure you know you’re doing something monstrously foolhardy.

If you’re in a public location, you can hide your password, to prevent people from peeking over your shoulder.

Screen Shot

This new interface is also integrated into the Add New User screen. By default, we won’t even reveal the password. We’ll just send the user a reset link.

Screen Shot

But if you’re in a non-email environment or would like to pass this password to the user in a secure method such as iMessage, Signal, or TextSecure, you can reveal it…

Screen Shot

The new interface can also be found on the password reset screen and the WordPress install screen. They all start you out with a long, random, unguessable password. Although WordPress isn’t stopping you from choosing terrible passwords, the default in 4.3 is that you get secure passwords, and making them less secure takes a bit of work.

In addition to this new UI, we have also stopped e-mailing passwords, so valid passwords aren’t going to sit in your e-mail inbox, waiting for some future e-mail hacker to gain access. Password reset links now expire in 24 hours by default. And when your password or e-mail changes, we send you an e-mail (in the case of e-mail, to your old address), so if someone hijacks your browser session and changes those critical items, at least you’ll be aware that it happened, and you can take action. You can disable these e-mails via the send_password_change_email and send_email_change_email filters (just have them return false).

Huge thanks to everyone who contributed code, testing, UI, and thoughtful feedback on this feature!

#4-3, #dev-notes, #passwords

Today in the Nightly: Customize in the Toolbar, Passwords UI, List Tables on Phones, Dashicons

Development leading up to the first beta brought several visual changes. These are available right now in the nightly build. Switch a site to nightly builds and try them out.

Customize in the toolbar

To disambiguate between links to the Customizer and links to the Appearance screens from the front-end, Customize now has a top-level toolbar button rather than having links to it mixed with dashboard links in the site menu. This context mixing leads to disrupted user expectations as they navigate, as well as experiences that feel slower or actually are slower in some cases. See #32924.

This means an additional top-level menu item, but the existing links to Widgets and Themes in the dropdown will now point to the admin, as the Dashboard and Menus links do. The advantage and goal for this change is to make it clear that you are about to enter the customizer. Deep links have not been added back in this go-round; this means that direct links to Header and Background are currently absent (with a very narrow exception related to old browsers). Those two deep links are still available in the admin menu under Appearance, which similarly mixes context but has not yet been addressed.

More changes are coming to the toolbar. Peek at a possibility for more general improvements to the toolbar, being discussed in #32678.

Phone friendly list tables

List tables now scale down to phones. The column truncation strategy they used before didn’t scale down to small screens. A single column layout with disclosures is the new strategy. Some of our most important screens use list tables, notably Media and Posts. Truncated columns was number 5 on our top  5 impediments to flow on touch devices list.

After:

Before:

See #32395.

For more screenshots, see these visual surveys of the list table screens.

Toolbar interaction fixes for touch devices

I’ve been wanting this one for a long time.  Toolbar interaction was number 3 on the top  5 impediments to flow on touch devices.

 

Fixed!

Fixed!

See #29906. That ticket is a good read.  It has: Visual feedback and visual surveys. Punting a working fix to the next release so that a new, more future proof approach could be tried. Development of touch capability detection. Working around iOS. Development of testing checklists. Lots of iteration.

Passwords UI

The password set/change UI was updated with these improvements.

  • Generate the password for the user
  • More tightly integrate password strength meter
  • Warn on weak passwords

See #32589 for more screenshots.

Dashicons update

Dashicons received a big update.

New icons:

  • .dashicons-admin-customizer (f540)
  • .dashicons-admin-multisite (f541)
  • .dashicons-editor-table (f535)
  • .dashicons-filter (f536)
  • .dashicons-hidden (f530)
  • .dashicons-image-filter (f533)
  • .dashicons-image-rotate (f531)
  • .dashicons-layout (f538)
  • .dashicons-sticky (f537)
  • .dashicons-thumbs-down (f542)
  • .dashicons-thumbs-up (f529)
  • .dashicons-unlock (f528)
  • .dashicons-warning (f534)

Updated icons:

  • .dashicons-plus (f132)
  • .dashicons-yes (f147)

dashicons-preview

See #30902.

Better styling for .form-invalid inputs

See #32490.

Responsive styling for my-sites.php

My Sites now moves to a single column layout on narrow viewports. Here it is on an iPhone 6, an iPad, and a Macbook, as well as at full-width.

Here’s what it looked liked before.

my-sites-before

See #31685 – Better responsive styling for my-sites.php

Crosslinking Customizer Panels

The graf in the Menus panel details about using the Customize Menu widget now links directly to the widgets panel.

customize menus details

See #32742.

You might notice the misaligned question mark icon on that screenshot. #32733 is tracking that.

 Easy switching between production and nightly builds

The beta tester plugin makes it easy to switch a site to nightly builds. Now switching back to the latest stable build is just as easy. It’s not the prettiest, but it is shown only to beta testers and will suffice until we finally refresh the Grand Unified Updater screen. For info on using the beta tester plugin to test with nightly builds, see the Beta Testing page of the core handbook.

See #32613.

 

Previously: Today in the Nightly: Site Icons, Text Editor in Press This

#beta-testing-flow, #customize, #dashicons, #list-tables, #multisite, #passwords, #today-in-the-nightly, #toolbar

The Plan for Passwords

For the 4.3 release, I’m leading the group working on passwords. We had a chat today, and here is our plan:

Re-work password choosing/changing UI

This has four main points:

  1. Default to generating a password for the user — if they want to choose their own password, they can, but the default should be that we generate a secure one for them.
  2. Default to showing the password input as plain text — to reduce typos, eliminate the second “confirmation”, and show them the password we’ve generated.
  3. In case of manual password entry, help them choose a better password — instead of just showing them how strong/weak it is, help them make it strong (“keep going… make your password longer!”).
  4. Make them jump through an “are you sure?” hoop to set a weak password.

We like the WordPress.com UI, and think we can derive some inspiration from that. Also, some work has already been done on #24633, which we could use as a starting point.

No manual or e-mailed passwords for creating other users

When creating an account for someone in WordPress, this is a bad time to let the user-creator pick a password. First, we’re risking that it’s weak, but even if it isn’t weak, it isn’t going to memorable for the actual user who will own the account. In this case, we should just generate a password, and send the user a password view/reset link.

Upon password reset, generate new password, and fill it in

When a password reset link is visited, we should set a new random password, log them in, and offer to show them the new password. Again, the idea is to discourage weak human-created passwords. They could still go in and choose a new one, but by default they’ll be getting a secure, random one.

Password reset links should expire

Besides being one-use, password reset links should expire after a short period of time.

Users should be notified of password/e-mail changes

If your password changes, or if you update the e-mail address on your account, that should generate an informational e-mail. (e.g. “if you made this change, then all is good”). In the case of the e-mail changing, the e-mail should go to the old address. This will prevent attackers from silently using XSS/CSRF to take ownership of accounts. There will be a record, now.

#4-3, #passwords