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

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

Focus v2 demo video

Here is the current state of the Focus v2 project, a re-think of Distraction Free Writing:

I would like to propose that we immediately merge this into core for 4.1.

Some of the bullet points:

  • Current Distraction Free Writing (DFW) interface is too much of a transition.
  • Current DFW doesn’t give you quick access to everything (you feel trapped in it).
  • Current DFW isn’t very discoverable.
  • New DFW (Focus v2) triggers on keyup (discoverable).
  • New DFW transition is seamless. Things you don’t need while typing just go away. Your scroll position is maintained. It’s the same editor, whereas before it was a separate one.
  • New DFW gives you instant access to all your meta boxes and everything else, with a wag of the mouse, a TAB press, or a tap.
  • Best of both worlds!

Not mentioned in the video is that the old DFW button now is a disabling toggle for this mode. So it’s Auto/Off, instead of On/Off.

#4-1, #dev-notes

9/10 Agenda

WordPress 4.0 “Benny” is out the door, warming hearts, flying off shelves, and many other euphemisms besides. After a brief respite to enjoy our success and a job well done, we turn our eyes to the future: 4.0.1, 4.1, and more.

#agenda, #meeting

About page for 3.6

As we approach 3.6 final, we need to start thinking about the About page for the release. What should go on it? Shout out your ideas.

#3-6

Hey Remember that WordPress 3.6 release we were…

Hey! Remember that WordPress 3.6 release we were working on? Yeah… we’re still at it. But there’s hope! Post Formats UI has been extracted, and Revisions has gotten an intense refactoring that makes it scale up to hundreds of revisions without killing your server or your browser. A backlog of many hundreds of tickets has been whittled down. As of this writing, we’re below 40 tickets for 3.6, and they’re actively being committed and punted as appropriate.

The plan is to keep on those tickets and get to RC by Friday. Help is appreciated! A bunch of people have been “pinged” regarding tickets on report/6, so please scan through those and log on to IRC to check for messages.

#3-6

We’re going to have some working IRC hours…

We’re going to have some working IRC hours tomorrow, June 6th, between 1400 UTC and 1800 UTC. Show up if you can and we’ll hammer away at the remaining items from this post!

Post Formats UI is exiting core, will live as a plugin

This is a hard decision. I’ve been talking to a lot of WordPress core developers and contributors, and the overwhelming consensus is that Post Formats UI is not ready for WordPress core, and that it would be a mistake to ship it as it currently exists. We’re going to pull it out, and let it continue development as a plugin, much like MP6.

I fought hard for it, and a lot of people put a lot of effort into it. But the result just isn’t compelling, or obvious, or any of the things that it should be. It’s not just a matter of polish, it seems to be a fundamental issue with the concept. The release can’t be held up any longer for this. It needs to come out. I should have made this decision earlier. That’s on me. But letting it ride would be the worse mistake.

Here is the proposed plan for extracting it, and for dealing with other tangentially related or other release-related items:

Post Format Things to Move to the Plugin

  • The posts screen UI, including icons in H2 #24452 #24502
  • Enabling all formats by default #24452
  • The custom screen options (go back to what we had before) #24452
  • The content/excerpt/title necessity modifications in wp_insert_post() #24503
  • Content area size changes #24452
  • structured-post-formats support and post_formats_compat() #24453 #24454
  • Revisioning of the post format and post format metadata keys #24455

Post Format Things to Keep in Core

  • Icons on edit.php (perhaps adding them to the radio format chooser to sync that context) #24519
  • post-new.php?format= shortcut
  • aside/status auto title generation (when blank)
  • URL extraction function (renamed from get_content_url() to get_url_from_post_content())
  • Post Format previewing #24483

Upgrade Path for Beta Dogfooders

  • Consider rolling upgrade that pieces together post_content based on existing meta keys
  • Alternatively, include this as a tool in the post formats plugin
  • Perhaps a WP-CLI component to the post formats plugin, so those upgrades can be done on the command line, once

Strategy for Media

  • Leave most of wp-includes/media.php — keep audio/video support
  • Call functions directly rather than calling do_shortcode() #24505
  • Have wp_get_(audio|video)_extensions() wrap wp_get_mime_types( $type = null ) if feasible #24504 (NOPE)
  • Remove or make sane attachment_url_to_postid() #24458
  • For A/V shortcodes, include the attachment ID, instead of just the URL (makes attachment_url_to_postid() unnecessary) #24458
  • Transition those IDs on import #24458
  • Consistency: embed shortcode takes URL as its content, but a/v ones take an attribute — make both for both? #24456

Shortcodes

  • Keep shortcode_exists() and has_shortcode()

What Else?

Did I miss anything? Is there something that doesn’t seem like the right path forward to you? Let’s hash this out so we can move on it.

The weekly IRC meeting has been moved back…

The weekly IRC meeting has been moved back one hour to 20:00 UTC. Still on Wednesdays. As always, check the sidebar for that info.

#irc

We’re really close

We’re so close to beta, I can taste it. For today’s meeting, think of anything outstanding that is still a beta blocker and then let’s talk about how we can get it sorted today. We’re going to keep at it until it’s ready. When? When it’s ready. But I’m hoping in the next 24 hours.