Best practice for resetting forgotten user passwords

Question

As far as I can think, there are two reasonable ways to reset a user's forgotten password.

1. Have the user enter their email address and a new plaintext password is sent to their email address.

2. A link is sent to their email address which has a UID number in the URL. Clicking on this takes the user to a form on the website where they can choose there own new password.

Which method is preferable and why?

If method 1 is used, perhaps a third party could read the email and obtain the new password. If method 2 is used, what is to stop someone methodically going through UID codes to try and access the form to change a user's password?

Solution 1

The best pattern would be :

1. User requests password reset. Best is to do it through username, and don't indicate if the username exists or not (to avoid possible users listing through a script)

2. You generate a record in a new database table with userid, datetime of request (= current datetime), and a GUID you just generated

3. You send a mail to the user, pointing to password reset page with the GUID (not the userid) as parameter

4. On this page, you should check that the GUID is existing, and eventually you could put some expiration date (=the user has 1 day to reset, for example)

5. Don't forget to mark the record as "used" (with an extra field in the table) when the user reset his password, so that you can stop an eventual second try...

It could possibly even more secure, but that is already quite good I think....

Solution 2

OWASP has a good checklist of https://www.owasp.org/index.php/Forgot_Password_Cheat_Sheet

Here is a quick summary of steps:

1. Gather Identity Data or Security Questions
2. Verify Security Questions
3. Send a Token Over a Side-Channel
4. Allow user to change password

Comments

[Ponting]

And how we handle that link if we are going with 2nd way. I am calling forgot password from iOS application and using FRAPI API(www.getfrapi.com).When user clicked on that link of mail then how we handle that mail's url ? through API or do we need external server ? I need help.

[arash moeen]

But you have to realize that email should always be the second way of communication in these situations, since user might not be able to access anymore the email or the email would not be valid at all. I'd recommend you to read this and get a good combination of ways to secure the procedure of reseting the password.

[Laurent S.]

Hi arash. Thanks for this link, it is indeed very interesting. The weakness in relying on email to reset password is not, as I see it, the password reset procedure, but the security on the email account. If this one is well secured the whole password reset procedure using it is also quite secure. That's one more occasion to insist on the need of a good security on email accounts, as they're for most people the "master key" to many other internet accounts and/or personal info.

[Laurent S.]

I just read yet another very interresting article on the same subject. A quite old article, but everything looks still valid. Here it is

[Michael]

The GUID should be hashed else it's no different to a plaintext password.

[Muhammad Umer]

why not hash it? if someone hacks db, then all people currently in middle of this are screwed.

[Laurent S.]

You should never ever send a password by email.

[cazort]

More generally, if you are even storing the passwords, there is an unnecessary security risk to your reviewers. Store only a one-way hash and make sure it's a strong hash.

[cazort]

I have found that a significant portion of users forget usernames and even emails that they have on file. If you do not provide any information to the user about whether or not the username and/or email they have entered is valid, you end up with a message that leads people to believe that they will have received a password reset link, but they have not. These users can get confused and frustrated and still have trouble accessing their account, whereas if they were notified that there is no email / username on file for whatever they typed in, they may remember the proper one. It's a tradeoff.

[cazort]

If your passwords are secure and you have other measures in place to prevent brute-force attacks, there is little downside to letting an attacker know that an account exists. In many cases, the site itself, including material with usernames, is public-facing so it is easy to find out usernames. There is slightly more concern with respect to email because emails are often private, but the worst-case scenario here is that an attacker learns that that email is associated with an account. You need to weigh that against the user experience.