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