This site is the archived OWASP Foundation Wiki and is no longer accepting Account Requests.
To view the new OWASP Foundation website, please visit https://owasp.org

Difference between revisions of "Testing for weak password change or reset functionalities (OTG-AUTHN-009)"

From OWASP
Jump to: navigation, search
Line 8: Line 8:
 
== Test objectives ==
 
== Test objectives ==
  
Determine the resistance of the application to subversion of the account change process allowing someone to change the password of an account.
+
Determine the resistance of the application to subversion of the account change process allowing someone to change the password of an account.<br>
 +
Determine the resistance of reset passwords functionality to guessing or bypassing.
  
Determine the resistance of reset passwords to guessing.
+
== Black Box Testing and Examples ==
  
== How to test ==
+
For both functionalities (password change and password reset) it is important to check:
 +
# if users, other than administrators, can change/reset passwords for accounts other than their own
 +
# if users can manipulate/subvert the password change/reset process to change/reset the password of another user or administrator
 +
# if the password change/reset process is vulnerable to CSRF
  
This test case aligns closely with OTG-AUTHN-007 - Testing for Weak Password Policy
+
=== Test Password Reset ===
# Can users other than administrators access change/reset passwords for accounts other than their own?
 
# Can users manipulate/subvert the password change/reset process to change/reset the password of another user or administrator?
 
# Is the password change/reset process vulnerable to CSRF?
 
# Are reset passwords generated randomly or using an algorithm the can be derived?
 
# How are reset passwords communicated to the user?
 
  
=== Example ===
+
In addition to the previus test it is important to verify:
  
 +
* What information is required to reset the password?
 +
The first step is to check whether secret questions/information are required. Sending the password (or a password reset link) to the user email address without first asking for a secret question means relying 100% on the security of that email address, which is not suitable if the application needs a high level of security.<br>
 +
On the other hand, if secret questions are used, the next step is to assess their strength. This specific test is discussed in detail in the [[Testing_for_Weak_security_question/answer_(OTG-AUTHN-008)|Testing for Weak security question/answer]] paragraph of this guide.<br>
 +
<br>
 +
* How are reset passwords communicated to the user?
 +
The most insecure scenario here is if the password reset tool shows you the password; this gives the attacker the ability to log into the account, and unless the application provides information about the last login the victim would not know that his/her account has been compromised.<br>
 +
A less insecure scenario is if the password reset tool forces the user to immediately change his/her password. While not as stealthy as the first case, it allows the attacker to gain access and locks the real user out.<br>
 +
The best security is achieved if the password reset is done via an email to the address the user initially registered with, or some other email address; this forces the attacker to not only guess at which email account the password reset was sent to (unless the application tells that) but also to compromise that account in order to take control of the victim's access to the application.<br>
 +
<br>
 +
* Are reset passwords generated randomly or not?
 +
The most insecure scenario here is if the application sends/visualizes the old password in cleartext because it means that passwords are not stored in a hashed form, which is a security issue in itself.<br>
 +
The best security is achieved if passwords are randomly generated with a secure algorithm that can not be derived.<br>
 +
<br>
 +
* Is the reset password functionality requesting confirmation before changing the password?
 +
To limit denial-of-service attacks the application should send, via e-mail, a link to the user with a random token, and only if the user visits the link the reset procedure is completed. So the current password should be valid until a successful reset is complete.
 +
<br><br>
  
 +
=== Test Password Change ===
  
== Tools ==
+
In addition to the previus test it is important to verify:
 +
 
 +
* Is the old password requested to complete the change?
 +
The most insecure scenario here is if the application permits the change of the password without requesting the current password, since if an attacker is able to take the control of a valid session he could easily change the victim's password.<br>
 +
 
 +
See also [[Testing_for_Weak_password_policy_(OWASP-AT-008)|Testing for Weak password policy]] paragraph of this guide.
  
 
== References ==
 
== References ==
  
 +
* [[Forgot_Password_Cheat_Sheet|OWASP Forgot Password Cheat Sheet]]
 +
* [[OWASP_Periodic_Table_of_Vulnerabilities_-_Insufficient_Password_Recovery|OWASP Periodic Table of Vulnerabilities - Insufficient Password Recovery]]
  
 
== Remediation ==
 
== Remediation ==
  
 
The password change/reset function is a sensitive function and requires some form of protection, such as requiring users to re-authenticate or presenting the user with confirmation dialogs during the process.
 
The password change/reset function is a sensitive function and requires some form of protection, such as requiring users to re-authenticate or presenting the user with confirmation dialogs during the process.

Revision as of 10:15, 7 March 2014

This article is part of the new OWASP Testing Guide v4.
Back to the OWASP Testing Guide v4 ToC: https://www.owasp.org/index.php/OWASP_Testing_Guide_v4_Table_of_Contents Back to the OWASP Testing Guide Project: https://www.owasp.org/index.php/OWASP_Testing_Project


Summary

The password change/reset function of an application is a self-service password change/reset mechanism for users. This self-service mechanism allows users to quickly change/reset their password without an administrator intervening. When passwords are changed they are typically changed within the application. When passwords are reset they are either rendered within the application or emailed to the user. This may indicate that the passwords are stored in plaintext.

Test objectives

Determine the resistance of the application to subversion of the account change process allowing someone to change the password of an account.
Determine the resistance of reset passwords functionality to guessing or bypassing.

Black Box Testing and Examples

For both functionalities (password change and password reset) it is important to check:

  1. if users, other than administrators, can change/reset passwords for accounts other than their own
  2. if users can manipulate/subvert the password change/reset process to change/reset the password of another user or administrator
  3. if the password change/reset process is vulnerable to CSRF

Test Password Reset

In addition to the previus test it is important to verify:

  • What information is required to reset the password?

The first step is to check whether secret questions/information are required. Sending the password (or a password reset link) to the user email address without first asking for a secret question means relying 100% on the security of that email address, which is not suitable if the application needs a high level of security.
On the other hand, if secret questions are used, the next step is to assess their strength. This specific test is discussed in detail in the Testing for Weak security question/answer paragraph of this guide.

  • How are reset passwords communicated to the user?

The most insecure scenario here is if the password reset tool shows you the password; this gives the attacker the ability to log into the account, and unless the application provides information about the last login the victim would not know that his/her account has been compromised.
A less insecure scenario is if the password reset tool forces the user to immediately change his/her password. While not as stealthy as the first case, it allows the attacker to gain access and locks the real user out.
The best security is achieved if the password reset is done via an email to the address the user initially registered with, or some other email address; this forces the attacker to not only guess at which email account the password reset was sent to (unless the application tells that) but also to compromise that account in order to take control of the victim's access to the application.

  • Are reset passwords generated randomly or not?

The most insecure scenario here is if the application sends/visualizes the old password in cleartext because it means that passwords are not stored in a hashed form, which is a security issue in itself.
The best security is achieved if passwords are randomly generated with a secure algorithm that can not be derived.

  • Is the reset password functionality requesting confirmation before changing the password?

To limit denial-of-service attacks the application should send, via e-mail, a link to the user with a random token, and only if the user visits the link the reset procedure is completed. So the current password should be valid until a successful reset is complete.

Test Password Change

In addition to the previus test it is important to verify:

  • Is the old password requested to complete the change?

The most insecure scenario here is if the application permits the change of the password without requesting the current password, since if an attacker is able to take the control of a valid session he could easily change the victim's password.

See also Testing for Weak password policy paragraph of this guide.

References

Remediation

The password change/reset function is a sensitive function and requires some form of protection, such as requiring users to re-authenticate or presenting the user with confirmation dialogs during the process.