Implementing a Secure Forgot Password Solution

balaji
By balaji

April 14, 2011

In the last article, we observed some of the common flaws in the implementation of the Forgot Password feature. This time we will take a look at one of the most common implementations of Forgot Password feature that we have seen in various banks and a drawback to this implementation that might very well be called as a chink in an otherwise impenetrable armor. We will also take a look at how we can implement a Forgot Password feature that addresses all possible threats.

secure-forgot-pwd.jpg

In the last article, we observed some of the common flaws in the implementation of the Forgot Password feature. This time we will take a look at one of the most common implementations of Forgot Password feature that we have seen in various banks and a drawback to this implementation that might very well be called as a chink in an otherwise impenetrable armor. We will also take a look at how we can implement a Forgot Password feature that addresses all possible threats.

Let's start by taking a look at a common implementation of the Forgot Password feature that we come across in banks. When a user clicks on the Forgot Password link, he/she is redirected to a page over SSL, which has the following form fields:

  • Customer ID
  • ATM/Credit Card No.
  • ATM/Credit Card PIN No.
  • New Password
  • Confirm New Password

Along with the above fields, there is also a CAPTCHA implementation in place, which will help stop automated brute-force attacks.

From an application security perspective, this implementation is pretty secure. Bypassing the feature is a very far-fetched probability and it is extremely simple and user-friendly. However, there is another area of concern wherein this implementation falls short and that is 'phishing'. Since the entire activity of resetting the password takes place on the same page, it makes the process of phishing user details a lot easier. Hence, we must always have a multistep implementation that will help in reducing the chances of a phishing attack.

So let's take a look at another way to implement the Forgot Password feature, which minimizes the probability of a successful attack on this feature. Although the 'best way to implement a Forgot Password feature' may be debatable, the following approach is one that we have observed to be very reliable. This approach may not be 'the best' but we can certainly claim it to be 'one of the best', while being pretty user-friendly at the same time.

  • When a user clicks on the 'Forgot Password' link, he/she is taken to a page served over SSL, which will ask the user for a unique identifying parameter like a username or e-mail ID. A CAPTCHA should be implemented on this page in order to prevent the generation of automated requests for Forgot Password.
  • Once the user enters the unique identifying parameter, an e-mail is sent to the user's registered e-mail account. This e-mail contains a one-time, short-lived link, which is mapped to the user account with the help of a randomly generated, non-reusable token.
  • When the user clicks on this link, he/she is redirected to another page on the site, served over SSL, which will ask the user a secret question that the user sets while registering. The user should be allowed a maximum of 5 attempts to answer the secret question.
  • Once the secret question has been successfully answered, the user is taken to the next page, again over SSL, which allows the user to set a new password. Once the user has successfully set a new password, he/she must be redirected to the Login page where they can log in with the new password that was set.

A few things that need to be taken care of while implementing the Forgot Password feature:

  • The link that is sent to the user's e-mail account allowing him/her to reset the password contains a token used to identify the user whose password has to be reset. This token should be a random, unique, one-time, short-lived token generated by the server. Otherwise, an attacker may be able to tamper with the token to reset the password of other users.
  • When the user clicks on the link and is taken to the page that asks the secret question, care must taken that the application does not actually log the user in or allows him/her access to any of the post-Login pages.
  • The old password should be invalidated only after the new password has been set. In case the old password gets invalidated when a user initiates a Forgot Password request, an attacker may be able to cause a Denial-of-Service to valid users by initiating a Forgot Password request on their behalf.

The implementation discussed above can be used for banking as well as non-banking applications. This implementation is just an overview of how things can be done. There can be variations depending on the application in question. I hope this article was useful and will be helpful for others in implementing a secure Forgot Password feature in their application.


Tags: Best Practices

About

balaji