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 Vulnerable Remember Password (OTG-AUTHN-005)"

From OWASP
Jump to: navigation, search
Line 4: Line 4:
 
== Summary ==
 
== Summary ==
  
The remember password function of an application is a self-service password reset/recovery mechanism for users. This self-service mechanism allows users to quickly reset/recover their password without an administrator intervening. Typically, in order to access this functionality the user must enter some form of identification, such as their username or email address.  
+
Browsers will sometimes ask a user if they wish to remember the password that they just entered. The browser will then store the password, and automatically enter it whenever the same authentication portal is visited. This is a convenience for the user.
 +
<br>
  
== Test objectives ==
+
== Description of the Issue ==  
 
+
Whilst a convenience for the user, having the browser storing passwords is also a convenience for an attacker.<br>
Evaluate the remember password function's user identification requirements. e.g. username, email address, security question
+
If an attacker can gain access to the victim's browser (e.g. through a Cross Site Scripting attack, or through a shared computer), then they can retrieve the stored passwords. It is not uncommon for browsers to store these passwords in a fully retrievable manner, but even if the browser were to store the passwords encrypted and only retrievable through the use of a master password, an attacker could retrieve the password by visiting the target authentication portal web site, entering the victim's username, and letting the browser to enter the password.<br>
 
 
Evaluate the method for how the reset/recovered password is communicated to the user
 
 
 
Evaluate the logic/workflow for how the password is reset/recovered
 
  
 
== How to test ==
 
== How to test ==
  
# Evaluate the level of identification that is required by the user to trigger a reset/recovery
+
* Enter a username and password in the target authentication portal and determine whether the browser asks the user whether they want the password remembered.
# Observe how the reset/recovered password is communicated to the user. e.g. email, rendered by browser
+
* View the authentication portal's HTML source code and look for the autocomplete="off" attribute in the password form field. The code for this will usually be along the following lines:
# Observe what steps are required to reset/recover password and what can be injected and falsified during this exchange
+
<pre>
 
+
<INPUT TYPE="password" AUTOCOMPLETE="off">
=== Example ===
+
</pre>
 
+
* Also look for passwords being stored in a cookie. Examine the cookies stored by the application. Verify that the credentials are not stored in cleartext, but are hashed. Examine the hashing mechanism: if it is a common, well-known algorithm, check for its strength; in homegrown hash functions, attempt several usernames to check whether the hash function is easily guessable. Additionally, verify that the credentials are only sent during the login phase, and not sent together with every request to the application. 
 
+
* Also look for other areas where a password may be entered, e.g. a Change Password form.
 
+
* Also consider other sensitive form fields (e.g. an answer to a secret question, used for Forgotten Password forms).
== Tools ==
 
 
 
== References ==
 
 
 
  
 
== Remediation ==
 
== Remediation ==
  
Implement additional identification requirements depending on the risk level. In order from lowest to highest assurance:
+
Any fields that contain sensitive information and passwords should be flagged in the HTML with AUTOCOMPLETE=”off”.
 
 
# username
 
# security question
 
# email address
 
# username and email address and security question
 
# positive identification based on physical attendance of user
 
 
 
Implement additional security to the transfer of the password to the user depending on the risk level. In order from lowest to highest assurance:
 
 
 
# Rendered by browser
 
# Unencrypted email
 
# Manually processed based on positive user identification and physically transferred by certified post or courier to user
 

Revision as of 11:31, 8 December 2013

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

Browsers will sometimes ask a user if they wish to remember the password that they just entered. The browser will then store the password, and automatically enter it whenever the same authentication portal is visited. This is a convenience for the user.

Description of the Issue

Whilst a convenience for the user, having the browser storing passwords is also a convenience for an attacker.
If an attacker can gain access to the victim's browser (e.g. through a Cross Site Scripting attack, or through a shared computer), then they can retrieve the stored passwords. It is not uncommon for browsers to store these passwords in a fully retrievable manner, but even if the browser were to store the passwords encrypted and only retrievable through the use of a master password, an attacker could retrieve the password by visiting the target authentication portal web site, entering the victim's username, and letting the browser to enter the password.

How to test

  • Enter a username and password in the target authentication portal and determine whether the browser asks the user whether they want the password remembered.
  • View the authentication portal's HTML source code and look for the autocomplete="off" attribute in the password form field. The code for this will usually be along the following lines:
<INPUT TYPE="password" AUTOCOMPLETE="off">
  • Also look for passwords being stored in a cookie. Examine the cookies stored by the application. Verify that the credentials are not stored in cleartext, but are hashed. Examine the hashing mechanism: if it is a common, well-known algorithm, check for its strength; in homegrown hash functions, attempt several usernames to check whether the hash function is easily guessable. Additionally, verify that the credentials are only sent during the login phase, and not sent together with every request to the application.
  • Also look for other areas where a password may be entered, e.g. a Change Password form.
  • Also consider other sensitive form fields (e.g. an answer to a secret question, used for Forgotten Password forms).

Remediation

Any fields that contain sensitive information and passwords should be flagged in the HTML with AUTOCOMPLETE=”off”.