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 candidaterelease candidate One of the final stages in the version release cycle, this version signals the potential to be a final release to the public. Also see alpha (beta).

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 UIUI User interface, 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 betaBeta A pre-release of software that is given out to a large group of users to trial under real conditions. Beta versions have gone through alpha testing in-house and are generally fairly close in look, feel and function to the final product; however, design changes often occur as part of the process. 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 CustomizerCustomizer Tool built into WordPress core that hooks into most modern themes. You can use it to preview and modify many of your site’s appearance settings. 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 adminadmin (and super 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 HeaderHeader The header of your site is typically the first thing people will experience. The masthead or header art located across the top of your page is part of the look and feel of your website. It can influence a visitor’s opinion about your content and you/ your organization’s brand. It may also look different on different screen sizes. 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 ticketticket Created for both bug reports and feature development on the bug tracker. 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 iOSiOS The operating system used on iPhones and iPads.. Development of testing checklists. Lots of iteration.

Passwords UIUI User interface

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-multisitemultisite Used to describe a WordPress installation with a network of multiple blogs, grouped by sites. This installation type has shared users tables, and creates separate database tables for each blog (wp_posts becomes wp_0_posts). See also network, blog, site (f541)
  • .dashicons-editor-table (f535)
  • .dashicons-filterFilter Filters are one of the two types of Hooks https://codex.wordpress.org/Plugin_API/Hooks. They provide a way for functions to modify data of other functions. They are the counterpart to Actions. Unlike Actions, filters are meant to work in an isolated manner, and should never have side effects such as affecting global variables and output. (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-invalidinvalid A resolution on the bug tracker (and generally common in software development, sometimes also notabug) that indicates the ticket is not a bug, is a support request, or is generally 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 widgetWidget A WordPress Widget is a small block that performs a specific function. You can add these widgets in sidebars also known as widget-ready areas on your web page. WordPress widgets were originally created to provide a simple and easy-to-use way of giving design and structure control of the WordPress theme to the user. 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 pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party 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 coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. 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 UIUI User interface

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.comWordPress.com An online implementation of WordPress code that lets you immediately access a new WordPress environment to publish your content. WordPress.com is a private company owned by Automattic that hosts the largest multisite in the world. This is arguably the best place to start blogging if you have never touched WordPress before. https://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