Forgot Password Cheat Sheet

Introduction

This article provides a simple model to follow when implementing a "forgot password" web application feature.

The Problem

There is no industry standard for implementing the "Forgot Password' featyre. The result is that users could be forced to jump through myriad hoops involving emails, special URLs, temporary passwords, personal security questions, and so on. In some applications you can recover your existing password. In others you have to reset it to a new value.

The recommendations presented for implementing "Forgot Password" are most appropriate for organizations that have a business relationship with users. Web applications that target the general public (social networking, free email sites, etc.) are fundamentally different and some concepts presented may not be feasible in those situations.

Steps

Step 1) Gather Identity Data

The first page of a secure forgot password feature asks the user for multiple pieces of hard data. A single HTML form should be used for all of the inputs.

A minimum of three inputs is recommended, but the more you require, the more secure it will be. One of the inputs, preferably listed first, should be the username. Others can be selected depending on the nature of the data available to the application. Examples include:

• email address
• last name
• date of birth
• account number
• customer number
• social security number
• zip code for address on file
• street number for address on file

Step 2) Verify Security Questions

After the form on Step 1 is submitted, the application verifies that each piece of data is correct for the given username. If anything is incorrect, or if the username is not recognized, the second page displays a generic error message such as “Sorry, invalid data”. If all submitted data is correct, Step 2 should display at least two of the user’s pre-established personal security questions, along with input fields for the answers. It’s important that the answer fields are part of a single HTML form.

Do not provide a drop-down list for the user to select the questions he wants to answer. Avoid sending the username as a parameter (hidden or otherwise) when the form on this page is submitted. The username should be stored in the server-side session where it can be retrieved as needed.

Step 3) Send a Token Over a Side-Channel

After step 2, email or SMS the user a randomly-generated code having 8 or more characters. This introduces an “out of band” communication channel and would be extremely tough for a hacker to overcome. If the bad guy has somehow managed to successfully get past steps 1 and 2, he is unlikely to have compromised the user’s email account.

Step 4) Allow user to change password

Require input of the correct code from step 3. Also require that Steps 1 and 2 have been answered correctly. Step 4 should (finally) allow the user to reset his password. Display a simple form with one input field for the new password and another field to confirm the new password. Make sure to enforce all password complexity requirements that exist in other areas of the application. As before, avoid sending the username as a parameter when the form is submitted.

Related Articles

Fishnet Security - Secure Forgot Password

OWASP Cheat Sheets Project Homepage

• OWASP Cheat Sheet Series

Authors and Primary Editors

David Furgeson - David.Ferguson[at]fishnetsecurity.com
Jim Manico - jim[at]owasp.org