Testing for Vulnerable Remember Password (OTG-AUTHN-005) - Revision history

Andrew Muller: Andrew Muller moved page Testing for Vulnerable Remember Password (OWASP-AT-006) to Testing for Vulnerable Remember Password (OTG-AUTHN-005): Align with Common Numbering

2014-08-05T13:26:36Z

Andrew Muller moved page Testing for Vulnerable Remember Password (OWASP-AT-006) to Testing for Vulnerable Remember Password (OTG-AUTHN-005): Align with Common Numbering

Jane O'Connor: Added Andrew's changes.

2014-08-01T19:44:59Z

Added Andrew's changes.

Jane O'Connor: Final edit

2014-05-14T17:54:43Z

Final edit

Raesene: typo

2014-04-17T15:29:37Z

typo

Raesene: Updated page to reflect change in browser handling of autocomplete="off" for password forms.

2014-04-17T15:29:19Z

Updated page to reflect change in browser handling of autocomplete="off" for password forms.

Lvsteche: Minor corrections/rewrites.

2014-03-22T08:22:35Z

Minor corrections/rewrites.

Davide Danelon at 12:27, 7 March 2014

2014-03-07T12:27:01Z

Davide Danelon at 12:26, 7 March 2014

2014-03-07T12:26:27Z

Robert WInkel at 11:31, 8 December 2013

2013-12-08T11:31:06Z

Andrew Muller at 14:36, 6 November 2013

2013-11-06T14:36:25Z

@@ Line 7: / Line 7: @@
 Additionally some websites will offer custom "remember me" functionality to allow users to persist log ins on a specific client system.
 Having the browser store passwords is not only a convenience for end-users, but also 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 an easily 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 web application's authentication form, entering the victim's username, and letting the browser to enter the password.
@@ Line 16: / Line 14: @@
-== Black Box Testing ==
+==How to Test ==
 * Look for passwords being stored in a cookie. Examine the cookies stored by the application. Verify that the credentials are not stored in clear text, but are hashed.

@@ Line 5: / Line 5: @@
 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 form is visited. This is a convenience for the user.
-<br>
+Additionally some websites will offer custom "remember me" functionality to allow users to persist log ins on a specific client system.
-Additionally some websites will offer custom "remember me" functionality to allow users to persist logins on a specific client system.
 == Description of the Issue ==
-== Black Box testing and example ==
+Having the browser store passwords is not only a convenience for end-users, but also 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 an easily 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 web application's authentication form, entering the victim's username, and letting the browser to enter the password.
-* Look for passwords being stored in a cookie. Examine the cookies stored by the application. Verify that the credentials are not stored in clear text, 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.
+== Black Box Testing ==
 * Consider other sensitive form fields (e.g. an answer to a secret question that must be entered in a password recovery or account unlock form).
 == Remediation ==
-Ensure that no credentials should to be stored in clear text or easily retrievable encoded/encrypted forms in cookies.
+Ensure that no credentials are stored in clear text or are easily retrievable in encoded or encrypted forms in cookies.

@@ Line 12: / Line 12: @@
 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 an easily 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 web application's authentication form, entering the victim's username, and letting the browser to enter the password.<br>
 Additionally where custom "remember me" functions are put in place weaknesses in how the token is stored on the client PC (for example using base64 encoded credentials as the token) could expose the users passwords.<br>
-Since early 2014 most major browsers will override any use of autocomplete="off" with regards to password forms and as a result previous checks for this are not required and recommendations should not commonly be given for disabling this feature. However this can still apply to things like secondary secrets which may be stored in the browser inadvertantly.
+Since early 2014 most major browsers will override any use of autocomplete="off" with regards to password forms and as a result previous checks for this are not required and recommendations should not commonly be given for disabling this feature. However this can still apply to things like secondary secrets which may be stored in the browser inadvertently.
 == Black Box testing and example ==

@@ Line 6: / Line 6: @@
 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 form is visited. This is a convenience for the user.
 <br>
 == Description of the Issue ==
 Having the browser storing passwords is not only a convenience for end-users, but also for an attacker.<br>
 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 an easily 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 web application's authentication form, entering the victim's username, and letting the browser to enter the password.<br>
 == Black Box testing and example ==
 * Look for passwords being stored in a cookie. Examine the cookies stored by the application. Verify that the credentials are not stored in clear text, 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.
 * Consider other sensitive form fields (e.g. an answer to a secret question that must be entered in a password recovery or account unlock form).
 == Remediation ==
-Any fields that contain sensitive information and passwords should be flagged in the HTML source code with AUTOCOMPLETE=”off”.<br>
+Ensure that no credentials should to be stored in clear text or easily retrievable encoded/encrypted forms in cookies.

@@ Line 4: / Line 4: @@
 == 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.
+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 form is visited. This is a convenience for the user.
 <br>
 == Description of the Issue ==
-Whilst a convenience for the user, having the browser storing passwords is also a convenience for an attacker.<br>
+Having the browser storing passwords is not only a convenience for end-users, but also for an attacker.<br>
-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>
+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 an easily 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 web application's authentication form, entering the victim's username, and letting the browser to enter the password.<br>
 == Black Box testing and example ==
-* Enter a username and password in the target authentication portal and determine whether the browser asks the user whether they want the password remembered.
+* Enter a username and password in the target authentication form 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:
+* View the authentication form's HTML source code and look for the autocomplete="off" attribute in the password form field. The code for this may resemble the following:
 <pre>
 <INPUT TYPE="password" AUTOCOMPLETE="off">
 </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.
+* Look for passwords being stored in a cookie. Examine the cookies stored by the application. Verify that the credentials are not stored in clear text, 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.
+* Look for other areas where a password may be entered (and hence be remembered by the browser), 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).
+* Consider other sensitive form fields (e.g. an answer to a secret question that must be entered in a password recovery or account unlock form).
 == Remediation ==
-Any fields that contain sensitive information and passwords should be flagged in the HTML with AUTOCOMPLETE=”off”.<br>
+Any fields that contain sensitive information and passwords should be flagged in the HTML source code with AUTOCOMPLETE=”off”.<br>
-Moreover no credentials have to be stored, in cleartext, into cookies.
+Moreover no credentials should to be stored in clear text in cookies.

← Older revision	Revision as of 13:26, 5 August 2014
(No difference)

@@ Line 2: / Line 2: @@
-== Brief Summary ==
+== Summary ==
-<br>
-..here: we describe in "natural language" what we want to test.
+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.
-<br>
-== Description of the Issue ==
+== Test objectives ==
-<br>
-...here: Short Description of the Issue: Topic and Explanation
+Evaluate the remember password function's user identification requirements. e.g. username, email address, security question
-<br>
-== Black Box testing and example ==
+Evaluate the method for how the reset/recovered password is communicated to the user
-'''Testing for Topic X vulnerabilities:''' <br>
-...<br>
+Evaluate the logic/workflow for how the password is reset/recovered
-'''Result Expected:'''<br>
-...<br><br>
+== How to test ==
 == References ==
-'''Whitepapers'''<br>
-...<br>
-'''Tools'''<br>
+== Remediation ==
-...<br>