Best way for a 'forgot password' implement

Question

I'm looking for the best method to implement a "forgot password" feature.

I come out with 2 ideas:

1. When user click on forgot password, the user is required to key in the username, email and maybe date of birth or last name. Then a mail with temporary password will be sent to the user email account. The user uses the temporary password to login and resets his password.

2. Similar, but the email would contain a link to let the user reset his password.

Or anyone can suggest me a better and secure way? I'm also thinking to send the temporary password or link, force the user to reset the password within 24 hour, or else the temporary password or link will not be usable. How to do that?

Answer 1

Troy Hunt makes some excellent points in his article, Everything you ever wanted to know about building a secure password reset feature. The most relevant excerpts are:

[T]here are two common approaches:

1. Generate a new password on the server and email it
2. Email a unique URL which will facilitate a reset process

Despite plenty of guidance to the contrary, the first point is really not where we want to be. The problem with doing this is that it means a persistent password – one you can go back with and use any time – has now been sent over an insecure channel and resides in your inbox.

...

But there’s one more big problem with the first approach in that it makes the malicious lockout of an account dead simple. If I know the email address of someone who owns an account at a website then I can lock them out of it whenever I please simply by resetting their password; it’s denial of service attack served up on a silver platter! This is why a reset is something that should only happen after successfully verifying the right of the requestor to do so.

When we talk about a reset URL, we’re talking about a website address which is unique to this specific instance of the reset process.

...

What we want to do is create a unique token which can be sent in an email as part of the reset URL then matched back to a record on the server alongside the user’s account thus confirming the email account owner is indeed the one attempting to reset the password. For example, the token may be “3ce7854015cd38c862cb9e14a1ae552b” and is stored in a table alongside the ID of the user performing the reset and the time at which the token was generated (more on that in a moment). When the email is sent out, it contains a URL such as “Reset/?id=3ce7854015cd38c862cb9e14a1ae552b” and when the user loads this, the page checks for the existence of the token and consequently confirms the identity of the user and allows the password to be changed.

...

The other thing we want to do with a reset URL is to time limit the token so that the reset process must be completed within a certain duration, say within an hour.

...

Finally, we want to ensure that this is a one-time process. Once the reset process is complete, the token should be deleted so that the reset URL is no longer functional. As with the previous point, this is to ensure an attacker has a very limited window in which they can abuse the reset URL. Plus of course the token is no longer required if the reset process has completed successfully.

He makes many more good points about avoiding information leaks, CAPTCHAs, two-factor authentication, and of course the basic best practices like password hashing. I think it's important to note that I disagree with Troy on the usefulness of security questions, preferring Bruce Schneier's skepticism of the practice:

The point of all these questions is the same: a backup password. If you forget your password, the secret question can verify your identity so you can choose another password or have the site e-mail your current password to you. It's a great idea from a customer service perspective -- a user is less likely to forget his first pet's name than some random password -- but terrible for security. The answer to the secret question is much easier to guess than a good password, and the information is much more public.

Answer 2

I'll go with:

1. Ask user for email, check email is registered
2. Generate GUID, and send it to that email
3. Do not reset password yet
4. User clicks link, and then have to enter new pass
5. Reset password only after user is in your site, and have clicked reset button after typing new pass.
6. Make that GUID expirable within a short time period to make it safer.

Answer 3

If you include an email address with the registration. The "forget password" button sends an email to that email address. It ensures that the information is send to a trusted email.

(Unless the database is hacked, but then nothing is safe).

Answer 4

Never email a password to the user. Even if it is auto-generated. Best approach (recommend and used by SANS and others):

1. On the forgot password page, ask the email/user id and a NEW password from the user.
2. Email a link to the stored email for that account with an activation link.
3. When the user clicks on that link, enable the new password.

If he doesn't click the link within 24 hours or so, disable the link (so that it does not change the password anymore).

Never change the password without the user consent. It means do not email a new password just because someone clicked on the forgot password link and figured out the account name.