Remove plaintext password sending

[Bloke]

This is 2015, and sending passwords via email in cleartext hasn't been cool since about 1971. Changes required:

• Drop 'mail it to me' feature when changing password on Admin panel.
• When creating new author, send a link in the welcome email to an admin screen that allows a password to be set. The link expires in N minutes (where N is configurable via a pref environment variable).
• Likewise when resetting a password: send the same reset link we do now, but instead of it regenerating the password and mailing it out, it'll prompt for a new password (+ confirmation?) in txp_auth.php and set it directly there on submit.
• New step(s) in txp_auth.php to permit the above functionality, with UI to allow the following features:
  • New password input box.
  • Confirmation input box?
  • Perhaps the ability to toggle the password input boxes between plaintext and asterisks. Although this could be deemed a security risk. And if there's the ability to see the password used, a second confirmation box is probably not necessary.
  • A little inline help showing examples of good password strategies. EDIT: removed for now until a suitable set of guidelines or i18n policy in zxcvbn can be fathomed.
  • A link to generate a random password (calls the internal functions we have now, perhaps via AJAX, and spits a new password to the screen with each click). EDIT: not implemented as it's poor security practice.
  • Possible strength meter, if deemed appropriate and we can find one that doesn't suck.
• Parts of the above may be extended to the setup routine too when creating the initial admin user (e.g. the 'get random password' link and 'password hint strategies' help text, maybe along with a strength meter).
• Rate limit the reset requests to an N minute window (e.g. 5) to prevent abuse from repeated password reset requests from the public side.

Anything else need adding to this list, or changing?

[Bloke]

Closed via 9bb6439, 084c9f3, 6d67824, 0b00c53, 2846140, and 8826cf9, among others.

[rwetzlmayr]

@Bloke:

When creating new author, send a link in the welcome email to an admin screen that allows a password to be set.

Though this item has been checked off, I cannot find this functionality anywhere in the admin-layout branch's code. Where would I have to look for it?

[Bloke]

Oops, hehe. Did multi-edit reset, but forgot to alter the New User code path at the same time. Will fix, thanks for the nudge.

[Bloke]

Regarding the new account registration invitations (formerly "your password is..."), how long is reasonable to allow them to remain active? The reset requests only last 20 mins by default because there's a good chance you sent the request yourself, so you'd be expecting it immediately.

But with account registrations being done by the administrator, the window will need to be wider. This opens up a security hole window of opportunity, somewhat mitigated by the fact that:

a) Intercepting or obtaining the email is the only real avenue of attack as the token is cryptographically strong, and;

b) The account is set up with a cryptograhically strong temporary password that is never intended to be logged in. It's just set because, without it, one could log in with no password.

When the recipient opens the 'activate' link they set their real password there and then, the token is invalidated and our window of opportunity closes (the user is then culpable, imo!)

If we're concerned about accounts in such limbo states, we could set them to None (or use a 'status' field to indicate activate, inactive, etc) and then set the appropriate real privs on activation, forbidding non-active accounts from logging in.

In short, there are many ways we can do this better, but we need to pick a good default time span for registration (a.k.a. activation/setting of first password) to remain open. Fingers in the air...

[rwetzlmayr]

About one week for my use case. The timeline goes like this:

• Site is ready for handoff to client
• I create user(s) for the site owner
• The site owner gets around to start working with their site, eventually meets their vendor contact (might not be me) who helps them with their initial login and explains the interface to them.

This whole arrangement might easily require a few days to complete, so a timeout window of roundabout one week is reasonable.

As a side-effect of this change we would probably need the ability to restart the signup sequence when the timeout window has lapsed. I think it is bad UX if we had to suggest a workaround like deleting and re-creating a user to restart from square one.

[Bloke]

A week sounds reasonable. Even though it's functionally identical to 'reset password' (albeit a different message sent to the user), a multi-edit "resend activation" option is next on the list.

[philwareham]

Is this complete now? Thanks.

[Bloke]

Just gotta add the timezone to one of the outgoing messages. Will do that now.