Stealing Password Reset Tokens for Fun and Profit

When adding a “Password Reset” function to your application it is especially important to ensure this has the same security considerations as any other critical function within the application. Due to the nature of resetting a user’s password, along with many security considerations being overlooked, it is not uncommon for attackers to spend extra time trying to bend these types of functions to their will to try and gain unauthorised access.

There are some key considerations that must take place when implementing this functionality to ensure it cannot be abused by attackers:

• it should essentially be impossible for an attacker to obtain in any manner a password reset token for another user,
• tokens must have a limited time span and be invalidated upon use,
• tokens must be authorised to only perform a password reset.

Let’s take a look in the case of an application Alchemy Security tested recently.

Problem one – static password reset tokens

For each user a password reset token was created at time of account creation and stored in the database as part of the credentials. This meant the account had a single reset token valid for the lifetime of the account, independent of how many times the user forgot their password.

As the token was not invalidated after a period of time or once used, this meant that even if the legitimate user reset their password, an attacker still had access to the token and in turn the account, another weakness detailed in problem two. It also appeared likely that the token could not be invalidated without deleting and re-creating the account.

The token was returned in a ‘HTTP 200 OK’ response from the API endpoint, so while not visible within the web page itself, was still easily obtainable by an attacker simply using an interception proxy such as Burp Suite. This meant that an attacker could easily write a script to test a list of usernames and obtain the token for each by parsing the resulting response.

To make matters worse, all of the above actions do not require any user authentication. Allowing an un-authenticated attacker to easily enumerate both usernames and their associated reset tokens without restriction or valid credentials.

Problem two – excessive token permissions & incorrect authorisation checks

The biggest problem was the token itself had excessive permissions and was able to perform almost any action for which the user already had permissions. For example, the token could be used to update the user’s profile (which then leaked the user’s password hash, another big issue!) or perform search functions to access data for which the user had access to.

These two issues meant that the application was prone to two critical security issues:

1. Account takeovers: An attacker able to obtain a reset token now had the ability to change a user’s email address associated with the account and perform an actual password reset (among other changes).
2. Application takeover: If an attacker targeted an admin account, they could essentially take full control of the application, locking out other administrator accounts and accessing all data within the application. Alternately, they could make changes to any other account of their choice, including escalating privileges of a low privileged account they already had access to.

These issues can be easily be avoided in the following manner:

• ensure reset tokens are only created once a user runs the “password reset” function,
• tokens must only be provided to the user requesting the reset via an email address previously validated and connected to the account and not returned via the web application front end,
• tokens must only be authorised to perform a reset and not have permissions for any other purpose,
• tokens must not be easily guessed, predictable or able to be brute forced.