Contact Login Register
h M

Secure Programming Tips - Password Reset Requests

Week 5: Forgotten Password Requests

Author: Chad Nash/Thursday, October 10, 2013/Categories: SQL Performance / Code Security

Rate this article:
No rating

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.



Number of views (3532)/Comments (-)

blog comments powered by Disqus

Enter your email below AND grab your spot in our big giveaway!

The winner will receive the entire Data Springs Collection 7.0 - Designed to get your website up and running like a DNN superhero (spandex not included).

united luxury shop
konulu porno
deneme bonusu maltcasino bahis siteleri
sex video free download in mobile hot sexy naked indian girls download free xxx video
antalya escort
atasehir eskort antalya escort bahcelievler escort alanya escort atasehir escort
porno izle
gaziantep escort gaziantep escort
escort pendik
izmir escort kayseri escort gaziantep rus escort
vdcasino casino metropol casinomaxi
beylikdüzü escort