Architecture for 2 Phase Password Reset Using OTP

Password reset is among the most common flows implemented in various kinds of software solutions, and it usually consists of 2 steps:

• Challenge   

The process of submitting a proof of identification for the user, like sending a code to an email or phone number previously registered for that user, then validating the user by checking the code sent against the one input by the user.

• Reset

The process following the success of the challenge, which includes submitting the new password.

Factors to consider

• One Time Password (OTP) can only be issued directly to the phone number and checked once by a system outside our scope.

• Password reset endpoint must be protected against unauthorized requests, therefore a password reset request must include a proof that the sender previously succeed in an OTP challenge related to this account.

Approach #1: Token table:

We can safely conclude that a very valid approach would be to use a session like architecture, where a session is created when the OTP is validated and a token is issued and stored to the database, this token also contains metadata about the session and its lifetime as well as the user account reference to avoid exploits where an issued token may be used to reset password for another user.

Session token tables are the industry standard for system managed state-fullness, and it also maintains a well-tested, rock-solid dependability in that regard.

But the hassle of managing a database IO and purging a heavily used table can be an overhead for many scenarios, comes in the next approach.

Approach #2: Single payload approach:

The single payload approach is even more logical than the token table approach, instead it reduces a call, and combine it with both.

In other words, the challenge response is stored in memory until the time to send the password reset request, then it’d be sent alongside for validation.

This approach is very much simpler and very dependable as it does not leak information via brute force, but lacks the ability to validate beforehand the challenge for input errors, this can be quite frustrating from a UX point of view.

Approach #3: Stateless token generator:

A stateless password reset token generator is an approach that combines the benefits of both previous ones, by using data that changes alongside the password. We can generate a token that is highly coupled to the password, which will automatically vanish from the system with the password change.

This approach relies on information like last password change date and the password hash itself. It uses such fields as components to generate a token, which will always be the same until the password is actually changed.

However, when relying on this approach many factors are to be considered.

1.  After the password reset challenge is successful and the token is issued, the account in question must be locked until the password update is concluded, meaning logging in to that account must be disabled until the password is actually updated.

2. Relying on as many fields as possible to issue the token is more than crucial to protect the hashed password as well as the algorithms themselves from any type of exposure

Conclusion:

Finally, to conclude, this process is highly variable in nature, and has many forces at play, therefore none of the solutions illustrated can be said to be one size fits all. However, each one of them has its strengths and weaknesses. The most important factor in the design of such solutions, is to ensure the utmost priority for the security of the password reset process, while maintaining the other guidelines such as performance and user experience as it fits.