The Standard Best Practice followed by Gmail and other public websites are as below:
- Ask the username and/or a Custom Security question
- Display a Captcha, after successful verification of username and/or Security Question
- Send a link to the user's registered email address. The link should have random token associated with it
- The link should be short-lived, one time use only, and SSL enabled.
- Once the user's resets the password, the link should no longer be usable.
For most applications the above solution should work fine. What the SSL enabled link does is that it never exposes the user's password to an external entity like Yahoo, Gmail or hotmail, and it never resets the password automatically.
We were brainstorming over this solution, and one of the concerns was that we are putting our trust on an external entity (like a yahoo, gmail or hotmail) to hold the key to reset our account passwords, albeit for a short period of time. For applications that hold critical or sensitive data and that still need to implement a web based forgot password solution, this may not be an acceptable solution.
We came up with a few enhancements to the above standard solution, here is how it goes.
The Plynt Secure Forgot Password Solution
- Provide a publicly available Password Reset page over SSL, which asks for the user ID and 3 non guessable hint questions along with a CAPTCHA.
- After a successful verification, allow the user to choose/enter a 6-character Temporary Authorization Pin/Token
- Email another short lived SSL enabled tokenized URL to the user's email address.
- On Clicking this tokenized URL, the user should be asked to enter the 6-character Authorization Pin/Token and the new password.
- Expire the tokenized URL and Temporary Authorization Pin/Token
- Notify the user that the password has been changed.
- Force the user to change new password on the first login after resetting the password.
The above solution has all the benefits of the standard solution, in addition to that, we are protecting against a scenario where external entities like gmail, yahoo or hotmail accounts are compromised or data within them are sniffed over the network (traffic over HTTP). We protect this by adding a 6-character Temporary Authorization Pin/Token that the user enters on the web application's forgot password page, and hence is only known to the user. Without this token, the short lived SSL enabled tokenized URL will not be able to reset the password. Thus we have fulfilled both "What you know" and "What you have" principles of security.