Make WordPress Core

Opened 17 years ago

Closed 14 years ago

Last modified 3 years ago

#5919 closed enhancement (fixed)

Password reset improvements

Reported by: pishmishy's profile pishmishy Owned by: scribu's profile scribu
Milestone: 3.1 Priority: normal
Severity: normal Version: 2.0.4
Component: Users Keywords: has-patch
Focuses: Cc:

Description

(Separating #2870 into two tickets. See that ticket for full history)

==Password Reset==

Resetting a password takes too many steps. There are two e-mail verification steps, when one would do. Once the initial verification link is clicked, the user should be provided with the new password (on the page, not just in an e-mail.) They also could be provided with a "set your password" form allowing them to set the password to something they'll remember, so they're not doing this again the next time they want to blog from the library.

Attachments (2)

5919.diff (6.3 KB) - added by scribu 14 years ago.
5919.2.diff (6.9 KB) - added by scribu 14 years ago.
input new password twice

Download all attachments as: .zip

Change History (46)

#1 @Denis-de-Bernardy
15 years ago

  • Component changed from Administration to Users
  • Keywords needs-patch added
  • Milestone changed from 2.9 to Future Release
  • Type changed from defect (bug) to enhancement

#2 @johnbillion
15 years ago

  • Cc johnbillion@… added

#3 @jeremyclarke
15 years ago

  • Cc jer@… added

This was discussed at length in the following WP Hackers thread, where no one gave a reason why the idea shouldn't be implemented.
http://groups.google.com/group/wp-hackers/browse_thread/thread/b1ab78c2b54572c2

#4 @scribu
14 years ago

Marked #14103 as dup.

#5 @demetris
14 years ago

  • Cc dkikizas@… added

#6 @RanYanivHartstein
14 years ago

I created a duplicate of this ticket that got closed, but the comments I posted on that ticket might be useful here too.

This happens in all recent versions of WordPress, and can be reproduced by trying to reset a password.

When users go to the lost password page, there is only one field for email address and one Submit button, so this is fine.

Then they get the first email with the confirmation, and this is where it gets confusing. The link opens a page that shows a notice and a log in form - but doesn't actually show the user their new password. Users need to read the instructions and only then they know that they should check their email *again* to find their new password.

However, most users won't read these instructions, for several reasons.

For one, resetting the password on a WordPress blog is more complicated then users are used to from other sites, so they may simply get frustrated when they realize they still don't have their password. If they don't check their email again soon, they may never notice the second message.

Also, the confirmation link leads to a log in form. In retrospect, this makes sense. The users has the log in form already open, and now all they need to do is go back to their email, find the new password, and use it in the log in form. However, this only makes sense *in retrospect*.

If the user doesn't already know how the password reset process works, they can either get sidetracked by the log in form and ignore the instructions all together (users often skip reading instructions when there are simple actions to perform, like filling a log in form or clicking a button), or get confused and click on Forgot Password again, creating an endless loop.

There are a few things we can do to make this less confusing.

The reset process can be less confusing. For e.g., the confirmation link can lead to a page where the new password is already displayed, or a form for choosing a new password, instead of sending a new password by email.

The confirmation link can lead to a page without any forms or buttons. If the confirmation links will just lead to a page that said "Check your email again, your password's there", it might be less confusing. The actual link to the log in page can be included in the final email.

#7 @holizz
14 years ago

  • Cc tom@… added

#8 @hew
14 years ago

FWIW, +1 to letting to user choose their own password in the reset process.

#9 @markel
14 years ago

  • Cc rmarkel@… added

+1.

Suggestion: provide a one-time-use link in the password recovery email (to verify the user's email address), which on clicking directs them to a form where they set a new password. It would be amazing if there was some kind of password-generation button there if they would like a secure, randomly generated password (a-Z, 0-9 only, no ambiguous characters permitted).

Should users be logged in immediately on setting the new password, or asked to enter it to log in again? The former seems preferable.

#10 @scribu
14 years ago

  • Milestone changed from Future Release to 3.1
  • Owner changed from anonymous to scribu
  • Status changed from new to assigned
  • Type changed from enhancement to task (blessed)

@scribu
14 years ago

#11 @scribu
14 years ago

  • Keywords has-patch added; needs-patch removed

5919.diff:

  1. User clicks the link in the Reset Password Mail
  2. User is presented with an input, where they can set a new password
  3. User sees this message: Your password has been reset. Log in

The user still receives an email with the new passord. Not sure if that's still necessary.

Potential improvements:

Add a password generator in step 2.

Instead of a link, show the login form directly in step 3.

#12 @nacin
14 years ago

Why can't it log them in automatically, then show an admin notice that says your password has been reset?

We need two inputs, including a confirmation.

#13 @nacin
14 years ago

I guess redirecting them to wp-admin might not always make sense such as in the case of subscribes, or the desire to limit them to wp-login.php and no further, but I don't see why they shouldn't be provided with the login cookies and then choose to go whence they came.

#14 @scribu
14 years ago

Logging them in automatically would be good.

As for confirmation, if you mean an AYS, they would have already opened the email and clicked on the link, which I think is confirmation enough.

#15 @nacin
14 years ago

No, I mean, typing in the password twice.

@scribu
14 years ago

input new password twice

#16 @scribu
14 years ago

  • Keywords ux-feedback added

5919.2.diff:

  • make the user enter the new password twice
  • don't send an email with the new password

#17 follow-up: @westi
14 years ago

Everytime someone makes me enter my password / email address twice a little bit of me dies inside.

I would rather the field they typed into was clear text than having to type twice

#18 in reply to: ↑ 17 @nacin
14 years ago

Replying to westi:

Everytime someone makes me enter my password / email address twice a little bit of me dies inside.

I completely agree about email, but password? If they type it wrong, they won't know until they log in, and then they have to do a reset again. Really bad UX. If anything, double boxes encourage stronger passwords because you're less likely to fail typing one.

I would rather the field they typed into was clear text than having to type twice

Disagree. Many people complain about passwords being visible. Database password I understand, but not user creation passwords and definitely not password resets. I'm paranoid about ever wanting to see my password in clear text, even knowing there's no one looking over my shoulder.

#19 @scribu
14 years ago

Related: #14939

#20 @scribu
14 years ago

  • Type changed from task (blessed) to enhancement

#22 @scribu
14 years ago

(In [15735]) Fix password reset procedure. See #5919

#23 follow-ups: @jane
14 years ago

  • Keywords ux-feedback removed

Current email text is:

Someone has asked to reset the password for the following site and username.

http://domain.tld

Username: jane

To reset your password visit the following address, otherwise just ignore this email and nothing will happen.

http://domain.tld/specialurl

I get these emails all the time b/c people try to change my password for some reason, and the poor grammar always bugs me.

Could the email be edited to say instead:

Did you forget your password? Someone requested that the password be reset for the following account:

http://domain.tld

Username: jane

If someone else requested this by mistake, just ignore this email and nothing will happen.

To reset your password, visit the following address:

http://domain.tld/specialurl

Don't forget, security begins at home, so please use a secure password to protect your account.

Thanks for using WordPress''

It would be ideal to pop the strength meter into the reset form, too. People are far more likely to change password using reset than by going into profile.

#24 in reply to: ↑ 23 @demetris
14 years ago

Replying to jane:

I get these emails all the time b/c people try to change my password for some reason, and the poor grammar always bugs me.

Could the email be edited to say instead:

The grammar of the current message seems OK to me.

A few observations about the proposed changes:

The subjunctive seems out of place there; especially for an app that greets you with Howdy. :-)

The security tip only helps to accentuate a bit more WordPress’s schizophrenia. (At one place it asks you if you want to change your secure password with a password easier to remember. At other places it suggests and generates random passwords — I have talked about that in another ticket.)

In general, I think that messages should try to convey what is essential for the interaction, and nothing more, using words that are as clear as possible and as few as possible. The current message does that.

#25 @scribu
14 years ago

(In [15776]) Improve password reset email copy. See #5919

#26 follow-up: @scribu
14 years ago

(In [15780]) move password-strength-meter.js into user-profile.js. See #5919

#27 @scribu
14 years ago

(In [15781]) Revert part of [15780] included by accident. See #5919

#28 @scribu
14 years ago

(In [15782]) first pass at strength indicator on password reset. see #5919

#29 in reply to: ↑ 23 ; follow-up: @Viper007Bond
14 years ago

Replying to jane:

I get these emails all the time b/c people try to change my password for some reason, and the poor grammar always bugs me.

I'm glad I'm not the only one bugged by the odd grammar. That e-mail is worded very weird.

#30 in reply to: ↑ 29 ; follow-up: @demetris
14 years ago

Replying to Viper007Bond:

Replying to jane:

I get these emails all the time b/c people try to change my password for some reason, and the poor grammar always bugs me.

I'm glad I'm not the only one bugged by the odd grammar. That e-mail is worded very weird.

What is that bugs you in that message? Is it the “otherwise” and the comma before a clause that is independent?

To reset your password visit the following address, otherwise just ignore this email and nothing will happen.

Here is the fix then:

To reset your password visit the following address. Or just ignore this email and nothing will happen.

No need to add all that other stuff.

But if we start nitpicking like this, we will have to change half of the strings in core.

#31 in reply to: ↑ 26 ; follow-up: @westi
14 years ago

Replying to scribu:

(In [15780]) move password-strength-meter.js into user-profile.js. See #5919

What is the logic behind merging this two separate pieces of js?

What if a plugin was using the password-strength-meter - have you not broken that?

#32 @JohnONolan
14 years ago

  • Cc JohnONolan added

Suggest moving #pass-strength-result to #pass-strength-meter to make it clearer and to match JS naming.

Is there any use-case (inc themes/plugins) where there would be more than on password strength meter on a page? If so then this should be a class rather than an ID.

#33 in reply to: ↑ 31 ; follow-up: @scribu
14 years ago

Replying to westi:

Replying to scribu:

(In [15780]) move password-strength-meter.js into user-profile.js. See #5919

What is the logic behind merging this two separate pieces of js?

What if a plugin was using the password-strength-meter - have you not broken that?

The logic was that everywhere in core they are used together.

Although I doubt a plugin would want to use one without the other, I guess I should have just fixed the dependency.

#34 in reply to: ↑ 30 @jane
14 years ago

Replying to demetris:

But if we start nitpicking like this, we will have to change half of the strings in core.

Yes. I was actually supposed to go through all strings back in 2.7 but it never got priority above other features, so it's been a bit here and a bit there to improve gradually. That means that yes, strings change. Changing them early in the cycle like this is intended to help give translators extra time, but we're not going to stop improving the text in WordPress just to avoid string changes.

#35 in reply to: ↑ 33 @westi
14 years ago

Replying to scribu:

Replying to westi:

Replying to scribu:

(In [15780]) move password-strength-meter.js into user-profile.js. See #5919

What is the logic behind merging this two separate pieces of js?

What if a plugin was using the password-strength-meter - have you not broken that?

The logic was that everywhere in core they are used together.

Although I doubt a plugin would want to use one without the other, I guess I should have just fixed the dependency.

Going to unmerge these.

#36 follow-up: @jane
14 years ago

When you click the forgot password? link, it shows:
Please enter your username or e-mail address. You will receive a new password via e-mail.

However, a new password is not emailed. Please change string to say:
Please enter your username or email address. You will receive a link to create a new password via email.

(As annoying as I find it personally, the general wp standard is email instead of e-mail, and website instead of web site.)

#37 in reply to: ↑ 36 @Viper007Bond
14 years ago

Replying to jane:

(As annoying as I find it personally, the general wp standard is email instead of e-mail, and website instead of web site.)

WordPress is actually correct in these cases.

There's a bit of debate about email, but the IETF and most dictionaries suggest "email": http://en.wikipedia.org/wiki/Email#Spelling

Unlike email, there's little debate that it's anything else: http://en.wikipedia.org/wiki/Website#Spelling While the term may have spawned out of being a site on the web (aka "web site"), "website" has become the de facto, if not even official, spelling.

#38 @westi
14 years ago

(In [15998]) Bring back a seperate js file for the password strength meter and correctly mark it as a dependancy of the user profile code. See #5919.

#39 follow-up: @nacin
14 years ago

When you are successful in choosing a new password, at the very least, you should see the login form. Better yet, you should be logged in, and you should see an admin notice that says your password has been changed. (Latter part has been signed off by Jane.)

Looking through the code, this does not look like it would be particularly easy without changing where things get posted to and the like. (When you realize you need a goto to make it work right, you know the code needs an overhaul.) Patches welcome.

#40 @automattor
14 years ago

(In [15999]) Make a string accurate. props jane, see #5919.

#41 @westi
14 years ago

(In [16000]) Remove the ghetto code and use the script loader properly on the login page.
Ensure that we actually have convertEntities available on the login page.
Introduce a login_footer action.
Hook in the script loader to the login_header and login_footer actions.
See #5919, #15124.

#42 in reply to: ↑ 39 @westi
14 years ago

Replying to nacin:

When you are successful in choosing a new password, at the very least, you should see the login form. Better yet, you should be logged in, and you should see an admin notice that says your password has been changed. (Latter part has been signed off by Jane.)

Looking through the code, this does not look like it would be particularly easy without changing where things get posted to and the like. (When you realize you need a goto to make it work right, you know the code needs an overhaul.) Patches welcome.

Are we still expecting to do this for 3.1 or shall we close and open a new 3.2-early ticket for that?

#43 @nacin
14 years ago

  • Resolution set to fixed
  • Status changed from assigned to closed

The workflow is not ideal, but it's also better than it was.

Closing as fixed for now, and opening a new ticket in 3.2 for a refactor.

Note: See TracTickets for help on using tickets.