View source for Testing for Weak security question/answer (OTG-AUTHN-008)

{{Template:OWASP Testing Guide v4}}


== 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.
<br>
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.
<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.
<br>

== 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.
<br><br>
'''Pre-generated questions:'''
<br>
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.
<br>
'''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:
<br>
* "What is 1+1?"
* "What is your username?"
* "My password is M3@t$p1N"
<br>
== Black Box testing and examples ==
'''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. 
<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.
<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.
<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.
<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:
** a “public” answer; for example, something Google would find with a simple query
** 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 
* 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 above point, 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.
<br><br>
== References ==
'''Whitepapers'''<br>
...<br>
'''Tools'''<br>
...<br>