Protiviti / SharePoint Blog

SharePoint Blog

June 01
Password Reset Flow: Best Practices for Custom Applications

I was recently asked by a client to write a password reset flow for a custom web application, with the ability to mass reset all passwords. Time was of the essence, and they had not interfaced with their SSO service using a custom application yet. I did the first thing any good developer/consultant would do when asked for proprietary custom module that has been repeated by many applications in the software world: I checked the internet for the industry standard.

However, there was no fully descriptive industry standard to replicate, so after studying the forgotten password flows of common apps we use today, and going through the process of creating my own, I decided to write a blog post outlining a pseudo-standard with specifications. I will first discuss what I gathered from the industry leaders and then go into detail about the flow that I created.

Industry Leaders – What they have in common

The general flow of the password reset process for each industry leader that I tested had pretty much the same features. The applications that I took a look at were Facebook, Twitter, and Gmail.

Each application provided the password reset option outside of the scope of a logged-in user so that users who forgot their passwords could also reset their passwords.

Each application had a recovery email on file to send emails that would kick off the password reset process. For each application, those emails contained a link back to the website with a temporary ID or token that would be used as a key into the resetting of the password and choosing a new one. After a user picks a new password and confirms it by keying in the password once again, a button is clicked, a reset confirmation email is sent, and the reset is complete.

Industry Leaders – What is different

Although the flow was very similar for our three industry leaders, there were some contrasting qualities for each. The length and syntax of the temporary tokens, the form of the tokens, and the other methods provided to reset the password (besides through email) were some of the main differences between the three applications.

Facebook uses a 6-digit randomly generated numeric token as their reset code. This code resets each time the user clicks the “Continue” button (photo #2 below). If the user tries an old code, he or she will redirected to an invalid token page. Facebook provides the code in the email as well as a link, both of which can be used to reset the password. Facebook also sends an email to each of the emails on file; the user does not have a choice in this.


Gmail, like Facebook, uses a 6-digit randomly generated numeric token as well. Unlike Facebook, Gmail does not reset the value of the token each time the user begins the reset process. For example, if the user requests a token to reset his or her password, never types that code in, and then requests a new token, the user will receive two emails with the same token value. Gmail only sends the password token emails to only the single recovery email on file, and provides only a code (no link).


Twitter is a bit different than both Gmail and Facebook. Twitter uses a 43-character alpha-numeric token along with a reset id, which is quite a bit more secure than the 6-digit tokens of both Gmail and Facebook. Twitter’s 43-character alpha-numeric would be virtually impossible to guess, with 36^43 possibilities (about 8.3*10^63 combinations). A numeric of length 6, on the other hand, would have just about a million possible combinations, pretty easily cracked by a brute-force hack. Twitter sends users their reset token in the form of a double encoded link; it does not provide a visible code to be copied and pasted like its Gmail and Facebook tech-leading comrades.

Password Reset window 

Encoded Reset Password Link:
Code block 

Token: GVmeSd07RmOe_bZbD_XfcC5L_1Y_wKLkYEIIHdBAL7U=-1526313952655

A side note on the industry leaders: All of them did have other options for resetting passwords, from storing and typing in old passwords, to texting the user’s phone on file, to using another account linked to the application. However, for the custom business application I was building, none of these were an option; therefore, I do not discuss them in this blog post.

My Reset Flow

Based on password reset flows of the industry leaders discussed already, I moved to create my own password reset flow for the application. The main specifications took the same form as the industry leaders that were discussed earlier, which I will outline in detail here. As for the token, I decided to align more with twitter as it appears to be more secure, at least on the surface. By that I mean Facebook and Gmail may have some additional brute force protection against malicious users trying to guess a valid password reset code of 6 numerics. I did not create the black hat application to see if they did. Regardless, for my application, I decided to go with the more secure token without the hypothetical brute force protection.

Forgot My Password Link and Page

  1. First, on the login page, or anywhere outside the logged in scope, the user clicks on a forgot password link that redirects the user to forgot my password page.

  2. On the Forgot Password page exists

    1. A form field for the user’s email address
    2. Contact information (tech support) and information regarding the password reset process
    3. Validation to verify that the user’s email addess takes the form of a real email address
    4. Submit button to trigger the email address submission and the reset process.
  3. Once an email address of correct form is entered and the submit button is clicked:

    1. The session cookie and the email address is sent to the server.
    2. The server processes the email address and validates the email address belongs to a valid user
    3. If the email address is valid, the server sends the user to the password reset completion/processing page and begins processing the reset request

Server-Side Processing of Reset Request

  1. Once the server validates the email address, it begins the reset password process and logs the request.

  2. The server randomly generates, with significant entropy, a password reset token of 48 uppercase and lowercase alpha-numeric chacters. The server stores the token in a database table along with the date and time of its creation, the email address of the creator, and the IP address of the browser associated with the reset request.

  3. To preserve the temporary-ness of the token:

    1. If a password reset token already exists in the database table for the user’s email address, it is removed.
    2. If a password reset token already exists in the database table for the user’s IP address, it is removed.
    3. A job will be run on a weekly basis to empty the temporary password reset table
  4. The server will send an email to the user’s email address containing the token encoded in a URL to the “new password page”.

Getting a new password

  1. The users receives the email with the encoded link containing the temporary and randomly generated token.

  2. The user clicks on the link which to a new view within the application where he or she can choose a new password. The token is passed to this new view as well via a URL parameter.

  3. On the new password page contains:

    1. Contact information (tech support) and information regarding the password reset process
    2. Two form fields for password entry. Both entries must be identical and contain at least 8 characters: at least one upper case alphabetic, one lower case alphabetic and one numeric.
  4. The page will contain a submit button that will initiate the server-side “password update” process and direct the browser to the “login” page.

  5. The submit button will also send the password reset token to the server-side “password update” process as a hidden field.

  6. The browser page direction to the “login” page will happen synchronously, but the server-side password update process will happen asynchronously.

Password Update Process

  1. Upon initiation of the server-side password update process, the server will compare the submitted password reset token to those stored in the database. If no token match is found, the process stops. If the token was stored more than 24 hours previously, the process stops.

  2. The server will examine the submitted new password for compliance with strength requirements. If not present or not sufficiently strong, the process stops.

  3. The server will store the new password in the user authentication table in the database, and remove the password reset token.

Quick Launch

© Protiviti 2021. All rights reserved.   |   Privacy Policy