Testing for Weak security question/answer (OTG-AUTHN-008) - Revision history

Mtesauro: /* Summary */ Updated an example to be more appropriate

2016-08-24T15:24:01Z

‎Summary: Updated an example to be more appropriate

Andrew Muller: Align with Common Numbering

2014-08-05T14:38:59Z

Align with Common Numbering

Jane O'Connor: Added Andrew's changes.

2014-08-01T19:52:58Z

Added Andrew's changes.

Jane O'Connor: Final edit

2014-05-14T18:17:43Z

Final edit

Lvsteche: Minor corrections/rewrites.

2014-03-22T09:22:01Z

Minor corrections/rewrites.

Robert WInkel at 12:33, 14 August 2013

2013-08-14T12:33:12Z

Robert WInkel at 12:02, 14 August 2013

2013-08-14T12:02:59Z

Robert WInkel at 11:57, 14 August 2013

2013-08-14T11:57:41Z

Robert WInkel at 10:19, 14 August 2013

2013-08-14T10:19:50Z

Robert WInkel at 10:16, 14 August 2013

2013-08-14T10:16:17Z

@@ Line 26: / Line 26: @@
 * "What is 1+1?"
 * "What is your username?"
-* "My password is M3@t$p1N"
+* "My password is S3cur|ty!"
 <br>
 == How to Test ==
 '''Testing for weak pre-generated questions:'''

@@ Line 3: / Line 3: @@
 == 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.
+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 (OTG-AUTHN-009)]]), or as extra security on top of the password.
 <br>
 <br>
@@ Line 40: / Line 40: @@
 '''Testing for brute-forcible answers:'''
 <br>
-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.
+Use the methods described in [[Testing for Weak lock out mechanism (OTG-AUTHN-003)]] to determine if a number of incorrectly supplied security answers trigger a lockout mechanism.
 <br><br>
 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.

@@ Line 2: / Line 2: @@
-== Brief Summary ==
+== 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.
 <br>
@@ Line 8: / Line 8: @@
 They are typically generated upon account creation and require the user to select from some pre-generated questions and supply an appropriate answer. They may 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.
 <br>
 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.
@@ Line 31: / Line 29: @@
 <br>
-== Black Box testing and examples ==
+== How to Test ==
 '''Testing for weak pre-generated questions:'''
 <br>

@@ Line 5: / Line 5: @@
 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.
 <br>
 <br>
-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.
+They are typically generated upon account creation and require the user to select from some pre-generated questions and supply an appropriate answer. They may 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.
 <br>
 == 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.
 <br><br>
@@ Line 21: / Line 21: @@
 * 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.
 <br>
 '''Self-generated questions:'''
 <br>
@@ Line 28: / Line 29: @@
 * "What is your username?"
 * "My password is M3@t$p1N"
 <br>
 == Black Box testing and examples ==
@@ Line 43: / Line 45: @@
 <br><br>
 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>
 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>
 * 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 “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 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?
 ** 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.
 <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 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>

@@ Line 11: / Line 11: @@
 == 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>
 '''Pre-generated questions:'''
@@ Line 23: / Line 23: @@
 '''Self-generated questions:'''
 <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>
 * "What is 1+1?"
@@ Line 32: / Line 32: @@
 '''Testing for weak pre-generated questions:'''
 <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>
 '''Testing for weak self-generated questions:'''
 <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>
 '''Testing for brute-forcible answers:'''
 <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>
-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>
 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>
-* 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?
-** 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>
-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>
 == References ==
 [http://www.schneier.com/essay-081.html The Curse of the Secret Question]
 <br>