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 security question/answer (OTG-AUTHN-008)"

From OWASP
Jump to: navigation, search
m (Minor corrections/rewrites.)
Line 11: Line 11:
  
 
== Description of the Issue ==  
 
== Description of the Issue ==  
Security questions and answers rely on the secrecy of the answer. Answers should be of the form that are only known by the account holder. However, although a lot of answers may not be publicly known, most of the questions that websites implement promote answers that are pseduo-private. Some examples are below.
+
Security questions and answers rely on the secrecy of the answer. Questions and answers should be chosen so that the answers are only known by the account holder. However, although a lot of answers may not be publicly known, most of the questions that websites implement promote answers that are pseudo-private.
 
<br><br>
 
<br><br>
 
'''Pre-generated questions:'''
 
'''Pre-generated questions:'''
Line 23: Line 23:
 
'''Self-generated questions:'''
 
'''Self-generated questions:'''
 
<br>
 
<br>
The problem with having users to generate their own questions is that it allows them to generate very insecure questions, or even bypass the whole point of having a security question in the first place. Here are some real world examples that illustrates this point:
+
The problem with having users to generate their own questions is that it allows them to generate very insecure questions, or even bypass the whole point of having a security question in the first place. Here are some real world examples that illustrate this point:
 
<br>
 
<br>
 
* "What is 1+1?"
 
* "What is 1+1?"
Line 32: Line 32:
 
'''Testing for weak pre-generated questions:'''
 
'''Testing for weak pre-generated questions:'''
 
<br>
 
<br>
Generate the security questions, e.g. by creating a new account, going through the forgotten password functionality, or whatever the process is for that particular system. Try to generate as many questions as possible to get a good idea of the type of security questions that are answered. If any of the security questions fall in the categories described above, they are vulnerable to being attacked (guessed, brute-forced, available on social media, etc.). If within scope of the testing engagement, the vulnerability could be exploited by the tester as further proof.  
+
Try to obtain a list of security questions by creating a new account or by following the “I don’t remember my password”-process. Try to generate as many questions as possible to get a good idea of the type of security questions that are asked. If any of the security questions fall in the categories described above, they are vulnerable to being attacked (guessed, brute-forced, available on social media, etc.).
 
<br><br>
 
<br><br>
 
'''Testing for weak self-generated questions:'''
 
'''Testing for weak self-generated questions:'''
 
<br>
 
<br>
Generate the security questions, e.g. by creating a new account, going through the forgotten password functionality, or whatever the process is for that particular system. If the system allows the user to generate their own security questions, it is vulnerable to having insecure questions created. If the system uses the self-generated security questions during the forgotten password functionality and if usernames can be enumerated (see [[Testing for Account Enumeration and Guessable User Account (OTG-IDENT-004)]]), then it should be easy for the tester to enumerate a number of users' self-generated questions. It should be expected to find several weak self-generated passwords using this method.
+
Try to create security questions by creating a new account or by configuring your existing account’s password recovery properties. If the system allows the user to generate their own security questions, it is vulnerable to having insecure questions created. If the system uses the self-generated security questions during the forgotten password functionality and if usernames can be enumerated (see [[Testing for Account Enumeration and Guessable User Account (OTG-IDENT-004)]]), then it should be easy for the tester to enumerate a number of self-generated questions. It should be expected to find several weak self-generated questions using this method.
 
<br><br>
 
<br><br>
 
'''Testing for brute-forcible answers:'''
 
'''Testing for brute-forcible answers:'''
 
<br>
 
<br>
Use the methods described in [[Testing for Weak lock out mechanism (OWASP-AT-004)]] to determine whether a number of incorrectly supplied security answers generates an appropriate lock out mechanism.
+
Use the methods described in [[Testing for Weak lock out mechanism (OWASP-AT-004)]] to determine if a number of incorrectly supplied security answers trigger a lockout mechanism.
 
<br><br>
 
<br><br>
The first thing to take into consideration when trying to exploit security questions is how many questions need to be answered? The majority of applications only need the user to answer a single question, but some critical applications require the user to answer correctly to two or even more questions.
+
The first thing to take into consideration when trying to exploit security questions is the number of questions that need to be answered. The majority of applications only need the user to answer a single question, whereas some critical applications may require the user to answer two or even more questions.
 
<br>
 
<br>
 
The next step is to assess the strength of the security questions. Could the answers be obtained by a simple Google search or with social engineering attack? As a penetration tester, here is a step-by-step walk-through of exploiting a security question scheme:
 
The next step is to assess the strength of the security questions. Could the answers be obtained by a simple Google search or with social engineering attack? As a penetration tester, here is a step-by-step walk-through of exploiting a security question scheme:
 
<br>
 
<br>
* Are there multiple questions offered? If so, focus on questions which have:
+
* Does the application allow the end-user to choose the question that needs to be answered? If so, focus on questions which have:
** a “public” answer; for example, something Google would find with a simple query
+
** A “public” answer; for example, something that could be find with a simple search-engine query
** a factual answer such as a “first school” or other facts which can be looked up
+
** A factual answer such as a “first school” or other facts which can be looked up
** few possible answers, such as “what make was your first car”. These questions 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  
+
** Few possible answers, such as “what model was your first car”. These questions would present the attacker with a short list of possible answers, and based on statistics the attacker could rank answers from most to least likely.
* Determine how many guesses you have (if possible)
+
* Determine how many guesses you have (if possible).
 
** Does the password reset allow unlimited attempts?
 
** Does the password reset allow unlimited attempts?
** Is there a lockout period after X incorrect answers? Keep in mind that a lockout system can be a security problem in itself, as it can be exploited by an attacker to launch a Denial of Service against legitimate users  
+
** Is there a lockout period after X incorrect answers? Keep in mind that a lockout system can be a security problem in itself, as it can be exploited by an attacker to launch a Denial of Service against legitimate users.
* Pick the appropriate question based on analysis from above point, and do research to determine the most likely answers  
+
* Pick the appropriate question based on analysis from the above points, and do research to determine the most likely answers.
 
<br>
 
<br>
The key to successfully exploiting and bypassing a weak security question scheme 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 security question scheme is only as strong as the weakest question.
+
The key to successfully exploiting and bypassing a weak security question scheme is to find a question or set of questions which give the possibility of easily finding 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 security question scheme is only as strong as the weakest question.
 
<br><br>
 
<br><br>
 
== References ==
 
== References ==
 
[http://www.schneier.com/essay-081.html The Curse of the Secret Question]
 
[http://www.schneier.com/essay-081.html The Curse of the Secret Question]
 
<br>
 
<br>

Revision as of 09:22, 22 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


Brief Summary

Often called "secret" questions and answers, security questions and answers are often used to recover forgotten passwords (see Testing for weak password change or reset functionalities (OWASP-AT-011)), or as extra security on top of the password.
They are typically generated upon account creation, and require the user to select from some pre-generated questions and supply an appropriate answer, or allow the user to generate their own question and answer pairs. Both methods are prone to insecurities.
Ideally, security questions should generate answers that are only known by the user, and not guessable or discoverable by anybody else. This is harder than it sounds.

Description of the Issue

Security questions and answers rely on the secrecy of the answer. Questions and answers should be chosen so that the answers are only known by the account holder. However, although a lot of answers may not be publicly known, most of the questions that websites implement promote answers that are pseudo-private.

Pre-generated questions:
The majority of pre-generated questions are fairly simplistic in nature and can lead to insecure answers. For example:

  • The answers may be known to family members or close friends of the user, e.g. "What is your mother's maiden name?", "What is your date of birth?"
  • The answers may be easily guessable, e.g. "What is your favorite color?", "What is your favorite baseball team?"
  • The answers may be brute forcible, e.g. "What is the first name of your favorite high school teacher?" - the answer is probably on some easily downloadable lists of popular first names, and therefore a simple brute force attack can be scripted.
  • The answers may be publicly discoverable, e.g. "What is your favorite movie?" - the answer may easily be found on the user's social media profile page.


Self-generated questions:
The problem with having users to generate their own questions is that it allows them to generate very insecure questions, or even bypass the whole point of having a security question in the first place. Here are some real world examples that illustrate this point:

  • "What is 1+1?"
  • "What is your username?"
  • "My password is M3@t$p1N"


Black Box testing and examples

Testing for weak pre-generated questions:
Try to obtain a list of security questions by creating a new account or by following the “I don’t remember my password”-process. Try to generate as many questions as possible to get a good idea of the type of security questions that are asked. If any of the security questions fall in the categories described above, they are vulnerable to being attacked (guessed, brute-forced, available on social media, etc.).

Testing for weak self-generated questions:
Try to create security questions by creating a new account or by configuring your existing account’s password recovery properties. If the system allows the user to generate their own security questions, it is vulnerable to having insecure questions created. If the system uses the self-generated security questions during the forgotten password functionality and if usernames can be enumerated (see Testing for Account Enumeration and Guessable User Account (OTG-IDENT-004)), then it should be easy for the tester to enumerate a number of self-generated questions. It should be expected to find several weak self-generated questions using this method.

Testing for brute-forcible answers:
Use the methods described in Testing for Weak lock out mechanism (OWASP-AT-004) to determine if a number of incorrectly supplied security answers trigger a lockout mechanism.

The first thing to take into consideration when trying to exploit security questions is the number of questions that need to be answered. The majority of applications only need the user to answer a single question, whereas some critical applications may require the user to answer two or even more questions.
The next step is to assess the strength of the security questions. Could the answers be obtained by a simple Google search or with social engineering attack? As a penetration tester, here is a step-by-step walk-through of exploiting a security question scheme:

  • Does the application allow the end-user to choose the question that needs to be answered? If so, focus on questions which have:
    • A “public” answer; for example, something that could be find with a simple search-engine query
    • A factual answer such as a “first school” or other facts which can be looked up
    • Few possible answers, such as “what model was your first car”. These questions would present the attacker with a short list of possible answers, 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 allow unlimited attempts?
    • Is there a lockout period after X incorrect answers? Keep in mind that a lockout system can be a security problem in itself, as it can be exploited by an attacker to launch a Denial of Service against legitimate users.
  • Pick the appropriate question based on analysis from the above points, and do research to determine the most likely answers.


The key to successfully exploiting and bypassing a weak security question scheme is to find a question or set of questions which give the possibility of easily finding 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 security question scheme is only as strong as the weakest question.

References

The Curse of the Secret Question