Forgot Password Cheat Sheet - Revision history

Dominique RIGHETTO: Point to the official site

2019-07-15T14:09:15Z

Point to the official site

Thunder-Son: Migration to GitHub

2019-02-14T11:34:44Z

Migration to GitHub

Dirk Wetter: "With some applications you can recover your existing password. " --> What? Something is utterly broken in terms of PW storage then

2018-08-31T15:38:54Z

"With some applications you can recover your existing password. " --> What? Something is utterly broken in terms of PW storage then

Sc00bz: /* Other Considerations */ Corrected successful password reset advice

2018-04-02T07:28:35Z

‎Other Considerations: Corrected successful password reset advice

Owaspdavef: Removed superfluous "Delete".

2017-05-22T15:26:42Z

Removed superfluous "Delete".

Michael McCabe at 19:13, 11 July 2016

2016-07-11T19:13:19Z

James Jardine: Undo revision 208025 by James Jardine (talk)

2016-02-03T04:09:56Z

Undo revision 208025 by James Jardine (talk)

James Jardine: Updated to switch Steps 2 and 3 to reduce risk of username harvesting.

2016-02-03T01:03:36Z

Updated to switch Steps 2 and 3 to reduce risk of username harvesting.

Jmanico: minor editorial cleanup

2015-09-15T20:23:02Z

minor editorial cleanup

Imifos: fixes punctuation marks, corrects layout

2015-09-06T06:28:54Z

fixes punctuation marks, corrects layout

← Older revision		Revision as of 14:09, 15 July 2019
Line 4:		Line 4:
	The Cheat Sheet Series project has been moved to [https://github.com/OWASP/CheatSheetSeries GitHub]!		The Cheat Sheet Series project has been moved to [https://github.com/OWASP/CheatSheetSeries GitHub]!

−	Please visit [https://~~github~~.~~com/OWASP/CheatSheetSeries/blob/master~~/cheatsheets/Forgot_Password_Cheat_Sheet.md Forgot Password Cheat Sheet] to see the latest version of the cheat sheet.	+	Please visit [https://cheatsheetseries.owasp.org/cheatsheets/Forgot_Password_Cheat_Sheet.html Forgot Password Cheat Sheet] to see the latest version of the cheat sheet.

@@ Line 2: / Line 2: @@
 <div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:Cheatsheets-header.jpg|link=]]</div>
-{| style="padding: 0;margin:0;margin-top:10px;text-align:left;" |-
+The Cheat Sheet Series project has been moved to [https://github.com/OWASP/CheatSheetSeries GitHub]!
-This article provides a simple model to follow when implementing a &quot;forgot password&quot; web application feature.<br>
+Please visit [https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Forgot_Password_Cheat_Sheet.md Forgot Password Cheat Sheet] to see the latest version of the cheat sheet.

← Older revision		Revision as of 15:38, 31 August 2018
Line 12:		Line 12:
	= The Problem =		= The Problem =

−	There is no industry standard for implementing a Forgot Password feature. The result is that you see applications forcing users to jump through myriad hoops involving emails, special URLs, temporary passwords, personal security questions, and so on~~. With some applications you can recover your existing password~~. In ~~others~~ you have to reset it to a new value.	+	There is no industry standard for implementing a Forgot Password feature. The result is that you see applications forcing users to jump through myriad hoops involving emails, special URLs, temporary passwords, personal security questions, and so on. In the end you have to reset it to a new value.

@@ Line 44: / Line 44: @@
 = Other Considerations =
-* Whenever a successful password reset occurs, the session should be invalidated and the user redirected to the login page.
+* Whenever a successful password reset occurs, all other sessions should be invalidated. Note the current session is already authenticated and does not require a login prompt.
 * Strength of questions used for reset should vary based on the nature of the credential. Administrator credentials should have a higher requirement.
 * The ideal implementation should rotate the questions asked in order to avoid automation.
 = Authors and Primary Editors  =

← Older revision		Revision as of 15:26, 22 May 2017
Line 18:		Line 18:

	== Step 1) Gather Identity Data or Security Questions ==		== Step 1) Gather Identity Data or Security Questions ==
−	~~Delete~~
	The first page of a secure Forgot Password feature asks the user for multiple pieces of hard data that should have been previously collected (generally when the user first registers). Steps for this are detailed in the identity section the Choosing and Using Security Questions Cheat Sheet [https://www.owasp.org/index.php/Choosing_and_Using_Security_Questions_Cheat_Sheet#Step_1.29_Decide_on_Identity_Data_vs_Canned_Questions_vs._User-Created_Questions here].		The first page of a secure Forgot Password feature asks the user for multiple pieces of hard data that should have been previously collected (generally when the user first registers). Steps for this are detailed in the identity section the Choosing and Using Security Questions Cheat Sheet [https://www.owasp.org/index.php/Choosing_and_Using_Security_Questions_Cheat_Sheet#Step_1.29_Decide_on_Identity_Data_vs_Canned_Questions_vs._User-Created_Questions here].

@@ Line 37: / Line 37: @@
 == Step 4) Allow user to change password in the existing session ==
-Step 4 requires input of the code sent in step 3 in the existing session where the challenge questions were answered in step 2, and allows the user to reset his password. Display a simple HTML form with one input field for the code, one for the new password, and one to confirm the new password. Verify the correct code is provided and be 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. Finally, it's critical to have a check to prevent a user from accessing this last step without first completing steps 1 and 2 correctly. Otherwise, a [[forced browsing]] attack may be possible.
+Step 4 requires input of the code sent in step 3 in the existing session where the challenge questions were answered in step 2, and allows the user to reset his password. Display a simple HTML form with one input field for the code, one for the new password, and one to confirm the new password. Verify the correct code is provided and be 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. Finally, it's critical to have a check to prevent a user from accessing this last step without first completing steps 1 and 2 correctly. Otherwise, a [[forced browsing]] attack may be possible. Ensure the user changes their password and does not simply surf to another page in the application. The reset must be performed before any other operations can be performed by the user.
 == Step 5) Logging ==

@@ Line 17: / Line 17: @@
 = Steps  =
-== Step 1) Gather Identity Data ==
+== Step 1) Gather Identity Data or Security Questions ==
 Delete
 The first page of a secure Forgot Password feature asks the user for multiple pieces of hard data that should have been previously collected (generally when the user first registers). Steps for this are detailed in the identity section the Choosing and Using Security Questions Cheat Sheet [https://www.owasp.org/index.php/Choosing_and_Using_Security_Questions_Cheat_Sheet#Step_1.29_Decide_on_Identity_Data_vs_Canned_Questions_vs._User-Created_Questions here].
-At a minimum, you should have collected some data that will allow you to send the password reset information to some out-of-band side-channel, such as a (possibly different) email address or an SMS text number, etc. to be used in Step 2.  Display a generic response, whether the username is valid or not, indicated that a link has been generated and sent.  This helps reduce the chance for username or email enumeration.
+At a minimum, you should have collected some data that will allow you to send the password reset information to some out-of-band side-channel, such as a (possibly different) email address or an SMS text number, etc. to be used in Step 3.
-==  Step 2) Send a Token Over a Side-Channel ==
+== Step 2) Verify Security Questions ==
-After step 1, lock out the user's account immediately. Then SMS or utilize some other multi-factor token challenge with a randomly-generated code having 8 or more characters. This introduces an “out-of-band” communication channel and adds defense-in-depth as it is another barrier 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 side-channel.  It is also a good idea to have the random code which your system generates to only have a limited validity period, say no more than 20 minutes or so. That way if the user doesn't get around to checking their email and their email account is later compromised, the random token used to reset the password would no longer be valid if the user never reset their password and the "reset password" token was discovered by an attacker. Of course, by all means, once a user's password has been reset, the randomly-generated token should no longer be valid. Avoid sending the user's username in the same email as the password reset link.
+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.
-== Step 3) Verify Security Questions ==
+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.
-Once the user clicks the reset link presented in Step 2, Step 3 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.
+Because users' security questions / answers generally contains much less entropy than a well-chosen password (how many likely answers are there to the typical "What's your favorite sports team?" or "In what city where you born?" security questions anyway?), make sure you limit the number of guesses attempted and if some threshold is exceeded for that user (say 3 to 5), lock out the user's account for some reasonable duration (say at least 5 minutes) and then challenge the user with some form of challenge token per standard multi-factor workflow; see #3, below) to mitigate attempts by hackers to guess the questions and reset the user's password. (It is not unreasonable to think that a user's email account may have already been compromised, so tokens that do not involve email, such as SMS or a mobile soft-token, are best.)
-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 ==
-Because users' security questions / answers generally contains much less entropy than a well-chosen password (how many likely answers are there to the typical "What's your favorite sports team?" or "In what city where you born?" security questions anyway?), make sure you limit the number of guesses attempted and if some threshold is exceeded for that user (say 3 to 5), lock out the user's account for some reasonable duration (say at least 5 minutes) and then challenge the user with some form of challenge token per standard multi-factor workflow; see #2, above) to mitigate attempts by hackers to guess the questions and reset the user's password. (It is not unreasonable to think that a user's email account may have already been compromised, so tokens that do not involve email, such as SMS or a mobile soft-token, are best.)
+After step 2, lock out the user's account immediately. Then SMS or utilize some other multi-factor token challenge with a randomly-generated code having 8 or more characters. This introduces an “out-of-band” communication channel and adds defense-in-depth as it is another barrier 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 side-channel.  It is also a good idea to have the random code which your system generates to only have a limited validity period, say no more than 20 minutes or so. That way if the user doesn't get around to checking their email and their email account is later compromised, the random token used to reset the password would no longer be valid if the user never reset their password and the "reset password" token was discovered by an attacker. Of course, by all means, once a user's password has been reset, the randomly-generated token should no longer be valid.
 == Step 4) Allow user to change password in the existing session ==
-Step 4 requires successfully answering the questions in Step 3, and allows the user to reset his password. Display a simple HTML form with one input field for the new password, and one to confirm the new password. 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. Finally, it's critical to have a check to prevent a user from accessing this last step without first completing steps 1 and 2 correctly. Otherwise, a [[forced browsing]] attack may be possible.
+Step 4 requires input of the code sent in step 3 in the existing session where the challenge questions were answered in step 2, and allows the user to reset his password. Display a simple HTML form with one input field for the code, one for the new password, and one to confirm the new password. Verify the correct code is provided and be 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. Finally, it's critical to have a check to prevent a user from accessing this last step without first completing steps 1 and 2 correctly. Otherwise, a [[forced browsing]] attack may be possible.
 == Step 5) Logging ==
@@ Line 56: / Line 56: @@
 Kevin Wall - kevin.w.wall[at]gmail.com<br/>
 James McGovern - james.mcgovern[at]hp.com<br/>
-Wesley Philip - wphilip[at]ca.ibm.com<br/>
+Wesley Philip - wphilip[at]ca.ibm.com

@@ Line 41: / Line 41: @@
 == Step 5) Logging ==
-It is important to keep audit records about when password change requests were submitted, whether or not security questions were answered, when reset messages were sent to users and when users utilize them.  It is especially important to log failed attempts to answer security questions and attempted use of expired tokens.  This data can be used to detect abuse and malicious behavior.  Data such as time, IP address, and browser information can be used to spot trends of suspicious use.
+It is important to keep audit records when password change requests were submitted. This includes whether or not security questions were answered, when reset messages were sent to users and when users utilize them.  It is especially important to log failed attempts to answer security questions and failed attempted use of expired tokens. This data can be used to detect abuse and malicious behavior.  Data such as time, IP address, and browser information can be used to spot trends of suspicious use.
 = Other Considerations =