August 27, 2013

How to secure password reset? The SALT approach!

Password reset has always been a challenge for organizations since incorrect implementation can cause to many additional expenses, e.g. more human resources, security breaches and other maintenance issues.
In this post, I would like to explain what should be done and even dive to details about the reason for each one of them.

Identification Channels

It doesn't matter if you allow password reset using SMS, mobile application, email or IVR systems. As long as you know how to identify the user, any of these details can be relevant.

Pre-reset actions

Many websites allow users to enter their identification channel and submit it to the server. In most cases, this request can be replied. As result, malicious user is able to reply the same request and cause to flooding attack on specific user, e.g. by sending too many emails of password reset.
In order to mitigate it, the website should use anti-bot and anti-reply mechanisms before the submission of the details, e.g. CAPTCHA.

Password management

This post does not focus on password management, but it is important to mention that all passwords in the system should be salted. That means that the system should store in the repository a random salt (I use UUID/GUID) and the hashed value, which created from the real password and the salt. The main reason for that will be clearer by the end of this post.

Reset password link

Following user's request to reset password, the system should generate encrypted string that contains at least the following values:
- Username - this is required to identify the user when he clicks the link.
- Timestamp - the time when the link created. This is important since it allows the system to control the time frame that this link should be active, e.g. if user entered the link two days following the link generation, it should not allow password reset.
- Password salt - This is important since it allows the system to create one-time link instead allowing to use the link many times within the timestamp above.

What should be done with the password salt that included in the link?

When user clicks the link, the system should identify the user against the repository and get his password salt from it. This salt should be equal to the salt that included in the link.
Following the verification of the password link, the user should choose his new password. When the system gets this password, the following steps should be done:
1. Change the password salt of the user to other random string.
2. Set the password hash using the value of the new password and the new salt.
In this case, if the user clicks the same link from above, the salt from the link should not be equal to the salt from the repository.

Reset password in other channels

If reset password link does not fit the specific channel (e.g. IVR), the common approach should be used. In this case, the system should manage other identification mechanisms, such as dummy questions, voice recognition etc.

2 comments: