Difference between revisions of "Testing for Vulnerable Remember Password and Pwd Reset (OWASP-AT-006)"

Revision as of 17:02, 2 November 2006

OWASP Testing Guide v2 Table of Contents

Brief Summary

Several web application allow users to reset their password if they have forgotten it, usually by sending him/her a password reset email or by asking them to answer one or more "security questions". In this test we check that this function is properly implemented and that does not introduce any flaw in the authentication scheme. We also check whether the application allows the user to store the password in the browser ("remember password" function).

Description of the Issue

A great majority of web applications provide a way for users to recover (or reset) their password in case they have forgotten it. The exact procedure varies heavily among different applications, but the approach is always to use an alternate way of verifying the identity of the user. The most common approach is to ask the user for his e-mail address, and send the old password (or a new one) to his/her address. This scheme takes for granted that the user's email is secure enough to use it for this goal. Alternatively (or in addition to that), the application could ask the user to answer one or more "secret questions". The security of this scheme lies in the ability to provide a way for someone to identify themselves to the system with answers to questions that are not easily answerable via personal information lookups. As an example, a terrible question would be “Mother’s maiden name” since that is something that can be had without extreme effort. An example of a good question would be “favorite grade-school teacher” since this would be a much more difficult topic to research about a person whose identity may otherwise already be stolen. Another common feature that applicatiosn use to help users with bad memory is the possibility of caching the password in the browser and having it 'pre-typed' in all subsequent accesses. While this feature can be perceived as extremely friendly for the average user, at the same time it introduces a flaw, as the user account becomes easily accessible to anyone that uses the same machine account.

Blackbox Testing and Examples

Password Reset
The first thing that should be done when testing a password self-reset function is assessing the questions (“secret questions”) presented to the potential password re-setter. Ask yourself whether you could obtain answers to any or all of these questions via a simple Google search on the Internet or with some social engineering attack. Often a self-reset system offers the choice of multiple questions; this is a good sign for the would-be attacker as this presents the attacker with options. As a potential attacker, here is a step-by-step walk through of assessing a password self-reset tool:

• Are there multiple questions offered?
  • If so, try to pick a question which would have a “public” answer; for example, something Google would find with a simple query
  • Always pick questions which have a factual answer such as a “first school” or other fact which can be looked up
  • Look for questions which have few possible options such as “what make was your first car”; this question would present the attacker with a short-list of answers to guess at and based on statistics the attacker could rank answers from most to least likely
• Determine how many guesses you have (if possible)
  • Does the password reset too allow you to guess at the answer to the secret question(s) forever?
  • Is there a lockout period after X incorrect answers?
• Pick the appropriate question based on analysis from above point, and do research to determine the most likely answers
• How does the password-reset tool (once a successful answer to a question is found) behave?
  • Does it allow immediate change of the password?
  • Does it display the old password?
  • Does it email the password to some pre-defined email address?
  • The best scenario here is if the password reset tool shows you the password; this gives you the ability to log into the account without the real user knowing that you’ve obtained access.
  • The second-best scenario is if the password reset tool allows you to immediately change your password. While not very stealthy, it gets the job done and gives you access and locks the real user out.
  • The worst-case scenario is if the password reset is done via an email to a email address the user initially registered with, or some other email address; this forces you to then to not only guess at which email account the password reset was sent to (unless the application tells you) but you now have to commandeer that account as well making this exercise much more complex.

The key to successfully exploiting and bypassing a password self-reset is to find a question or set of questions which give the possibility of easily acquiring the answers. Always look for questions which can give you the greatest statistical chance of guessing the correct answer, if you are completely unsure of any of the answers. In the end, a password self-reset tool is only as strong as the weakest question.

Password Remember

A "remember my password" mechanism can be implemented in one of the following methods:

1. Allowing the "cache password" feature in web browsers. Although not directly an application mechanism, this can and should be disabled.
2. Storing the password in a permanent cookie. The password can be either hashed or cleartext.

For the first method – check whether you can tell your browser to cache this password. This feature should be disabled, especially in sensitive applications. To check the second implementation type – examine the cookie stored by the application. Verify the credentials are not stored in cleartext, but are hashed. Examine the hashing mechanism, if it appears a common well-known one, check for its strength, in homegrown hash functions – attempt several usernames to check whether the hash function is easily guessable. Additionally, verify the credentials are only sent during the login phase, and not sent together with every request to the application.

Check the code to see whether browser caching of the passwords is disabled. The code for this will usually be along the lines of <INPUT TYPE="password" AUTOCOMPLETE="off">. If the credentials are stored in the cookie examine the code to understand the structure of the cookie, the hash function, and the usage of this cookie within the application.

References

Whitepapers
...
Tools
...

This article is a stub. You can help OWASP by expanding it or discussing it on its Talk page.

OWASP Testing Guide v2

Here is the OWASP Testing Guide v2 Table of Contents OWASP Testing Guide v2 Table of Contents