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)"
(Minor corrections/rewrites.) |
(Updated page to reflect change in browser handling of autocomplete="off" for password forms.) |
||
| 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. | 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> | <br> | ||
| + | Additionally some websites will offer custom "remember me" functionality to allow users to persist logins on a specific client system. | ||
== Description of the Issue == | == Description of the Issue == | ||
Having the browser storing passwords is not only a convenience for end-users, but also 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 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> | 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. | ||
== Black Box testing and example == | == 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. | * 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). | * 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 == | == Remediation == | ||
| − | + | Ensure that no credentials should to be stored in clear text or easily retrievable encoded/encrypted forms in cookies. | |
| − | |||
Revision as of 15:29, 17 April 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
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.
Additionally some websites will offer custom "remember me" functionality to allow users to persist logins on a specific client system.
Description of the Issue
Having the browser storing 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.
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.
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.
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
Ensure that no credentials should to be stored in clear text or easily retrievable encoded/encrypted forms in cookies.
