Aral Balkan

I just stumbled on the best "forgot password" implementation I've seen on event registration site Amiando.

You've no doubt seen various implementations of this UI pattern: all of these rely on using your email address to verify that you are indeed the user requesting the password reminder (or reset). But – as with everything else in UX – the devil's in the details (it's about The Little Things), as they say.

I keep coming up against two implementations that seem to have become de-facto standards:

• Create a random password, email it to the user, and then get them to confirm the password reset via email. Although not a horrible approach, it has two shortcomings. For one thing, you're creating a random password (that the user will forget if she doesn't change it – which requires yet more effort) and you are emailing the password to the user (which is insecure).
• Get the user to click a link in the email that takes them to your site and ask the user to enter a new password. This is better than the first method since the user will be entering their own password, which they will (hopefully) remember easier than a random one.

Amiando's form, however, implements a subtle evolution on the second method that makes the process even easier: on the initial form, they ask you for the new password. It's a simple little thing but it does mean that they've grouped the bit that requires cognitive load in one place. Now, all I have to do is click the link in the email to confirm my request and I'm up and running with my new password. It also means that the confirmation link has a single function and that its meaning is not overloaded to mean "confirm this request and then go on the site to pick a new password".

A few caveats

The Amiando implementation does fall flat on two important details however:

Firstly, it doesn't remember your email address. Since you've already entered your email address while trying to sign in, the forgotten password form should remember that email address to save you effort. I've seen this error made by nearly every forgotten password form I've encountered, so other developers should take note. It's not a difficult refinement to implement and it will result in an instant usability boost for your app (especially at a time when the user, not being able to sign in, is already frustrated).

Secondly, when you click on the link to confirm your new username and password, the site doesn't sign in you in automatically. Since it has confirmed your identity at this point and knows that you were trying to sign in, it should take the initiative and save you some effort.

(One of the worst implementations of this pattern that I saw actually changed your password without confirmation and then sent you an email with the new password. What a nightmare! Using that system, anyone could force a password change on your account on a daily basis, thereby forcing you to sign in and change your password back and probably driving you insane in the process.)

Check out the Amiando forgotten password form.

Comments

• Ohhh! i didn't read the verification part. That's actually really sweet!

  by Connor on 2010-06-28 13:32:59

• This approach does have one potential problem: if the owner of the password is not paying proper attention and clicks on a confirmation link they did not request, the attacker immediately has their password. The text of the email would have to be dramatic enough to warn of this. However, anyone who clicks idly in emails these days probably won't have their password for long anyway :)

  by Hamish on 2010-06-14 20:21:18

• The form says my password will be emailed to me. If this is true, it is worth noting. Having a fresh password emailed in plain text should certainly qualify as one more caveat.

  by peter on 2010-07-06 23:04:06

• What happens when someone get a hold of an email that isn't theirs, resets the password, logs in becuase they now know the username and password and then change the email associated with the account and the password. The original owner if completely locked out.

  by Connor on 2010-06-28 13:30:39

• This is a much better step than getting to have the password reset, luckily, I was about to implement it and came across this make my life more easier!

  by James on 2010-06-14 11:59:57

• You're welcome, Armin – glad I could be of help & looking forward to your updates :)

  by Aral on 2010-06-14 10:54:15

• Thank you for the article and the kudos :) I also did not like most implementations of the forgotten password feature, thats why we tried to improve it. About the caveats: You are absolutely right, it should remember the email of course and it is also implemented to behave this way. I will take a look why it doesnt work as intended currently and fix it. And you are also right about the auto login: If someone gets access to the email account he could change the password of the account anyways, so asking for the password again offers no additional protection. Thanks for the hints :) Armin

  by Armin Bauer on 2010-06-14 10:26:27

• your suggestion has a security problem, if I write a script that automatically fills out the form with "guessed" email adresses (generated from adress lists etc.) and a my password, I'm sure there will be a small percentage of email recipients confirming the link not knowing what exactly they are going to do there. after a couple of hours my script could easily break those confirmed accounts using my password...

  by axel on 2010-06-15 22:07:52

• Isn't security an issue here, especially if it automatically logged me in? For example, if I know your email address and know you're a member of the site, all I have to do is visit the forgot password page and I'm in.

  by Richard on 2010-06-14 13:37:10

• Whoops, I see now you said it should log you in AFTER you click the link. So really the only problem here is that you could get a lot of emails caused by someone trying to change your password, but the same is true in the other implementations as well.

  by Richard on 2010-06-14 13:39:04

• I'm all for innovative ideas. They keep us from getting into a stale groove. However, unless you have left out a step, I think this idea needs a serious revisit for the obvious security issue. Scenario: If I know your email address and initiate the password reset with a password of my choosing, all I need you to do is click a link. If I login and change your email address before you realize what happened and change the password again, I would own your account. You can see my latest implementation of a password reset feature here: http://acoderslife.com/index.cfm/blog/Careful-not-to-innovate-yourself-a-new-security-hole Basically, it just sends you a link that logs you in. From there, you can just update your profile with a new password. Of course, I am on the inside looking out on this one so feel free to scrutinize :-)

  by BobbyH on 2010-06-15 23:18:11

• Getting the user to re-enter the password after they click on the confirmation link before the new password is made official seems to be a way to add one more level of security to this pattern by proving you know the new password. It would deal with the issue of someone blindly clicking a link from the new source.

  by Bryan Rice on 2010-07-19 18:54:58

• Smart & simple. Made my day! :-)

  by Yanay Zohar on 2010-07-01 14:41:59

• Aral, we've been using the same password-reset pattern as Amiando for some time, and we've found it works well. We use a similar pattern for new account sign up on Hashwork. Sign up form is right on home page, you enter your email and pick a password, then you get a link which verifies, and signs you in.

  by Prakash on 2010-08-09 18:23:15

• I have a document that I downloaded in 2008 I don't remember ever using a password on the free reader program. When I try to open the 3 year old document a password is called for. What can I do?

  by Charles Waggoner on 2011-08-26 19:22:30

• Hamish - I was thinking this exact same thing - the password must not be changed immediately on a single click from the email, because it is all too easy for it to be clicked without thinking. If the email link instead takes the user to a page where they need to re-enter the password they have chosen, just once, then that will prevent any accidental changing of their password. It also means the password entered in the very first form does not need to be stored in any retrievable form - it can be [one-way] hashed and compared against the "confirmation page" password that is entered. It is that final password entered by the user that is sent for storage. In my particular application, the passwords are stored in an offline CRM. The website sends the plain text passwords to the CRM (over an encrypted connection) and the website has no involvement in the way that password is hashed within the CRM. This means I can't hash the password into its final form when the user first requests a password change. I like this approach. -- Jason

  by Jason Judge on 2011-10-26 17:04:13

• Great post and I like the approach of changing my password. I say changing because that's what the process actually does. I don't agree with the site remembering my email on the change password page as I'm not authenticated at that point. More importantly, how often can I attempt that change? Hopefully it is restricted to at the most 3 attempts from a single ip address and for the same email address within 24 hours. I don't want a bot changing my password every second and flooding my email. I agree with the second suggestion logging me in on confirmation , Thanks for the post.

  by Frank Gebhardt on 2012-03-06 18:11:26

• i'm forgot my password pattern

  by hanis on 2012-09-01 09:02:46

• Hello! With this approach adversary is able to change passwords to known value to a big number of users and wait patiently until some of them would confirm his password of choice.

  by Anton on 2012-12-25 09:08:10