Week 5: Forgotten Password Requests

As developers, it’s important for us to create user friendly applications. User friendly applications are those that are intuitive to an end user, as well as those that provide functionality for a user to address any issues the might arise while using it. A common issue that can arise is when an end user has forgotten their password. This can be very frustrating for a user, and often requires the end user to call a helpdesk for assistance in resetting the password. This can often result in a loss of productivity for the end user. So what can developers do to alleviate the end user’s frustration? Simple, we can build the functionality into the application itself. It’s fairly simple to create and only requires gathering one or more credentials known only to the end user, such as a username, account number, email address, etc. to verify the person making the password reset request is a valid user of the application.

Figure 1 below shows an example of a reset password request page.

                        Figure 1

Upon entering the required credentials above, the first step in the process would be to perform some application login on the credentials entered to ensure they are valid. The next step in the process, assuming the credentials supplied above are valid, is to determine how we are going to allow the user to reset their password. One option, albeit the worse possible one, would be to allow the user to create a new password at that time, such as shown in figure 2.

                        Figure 2

The primary reason the option above is a bad idea is, because if a lockout policy is not enforced, i.e. after a certain number of failed reset password request attempts, this could allow a malicious user to perform a brute-force attack and potentially discover and reset the passwords for valid user accounts, thus causing an application level DoS (Denial of Service) on the applications user base.

Another, more widely used option, is to send an email to the user’s email address containing a temporary password that would allow the user to login and then change their password to something more permanent. However, this option as well has security issues associated with it. The first issue is obviously the assumption that the user’s email address is only accessible to the user and not by any other person. The second issue, which happens quite often, is the email contains more information then it should, as seen in Figure 3.

Figure 3

As we can see in Figure 3 above, not only did the application send the new password, in clear text, but it also send additional credentials associated with the user’s account, including the user’s username, account number and the link to login with the new credentials. If the user’s email address was accessible by someone else, this email provides everything they would need to compromise and control the user’s account.

Realistically, if you are going to use an email exchange in order to allow the user to reset a forgotten password. The most secure manner is to provide a link containing a globally unique identifier (GUID) as a security token representing a one-time request. This link and associated security token should only be accessible for no more than 30 minutes. This will reduce the risk of the account being compromised in the event someone else has access to the user’s email account. Figure 4 is an example of a password reset email containing a secure link to change the user’s password.

Figure 4

As we’ve seen from the examples provided in this article, there are good ways and bad ways to allow a user to reset their password. Obviously, we don’t want to do all the actions at once, unless a lockout policy is in place. When using the user’s email address to communicate the password reset process, we obviously do not want to send all of the user’s credentials, nor do we want to send anything in clear text. The best recommendation, in lieu of a phone call to the help desk, is to provide the user with a secure link that is only accessible for a limited time frame, thus reducing the risk of the user’s account being compromised.