Testing for Weak security question/answer (OTG-AUTHN-008)
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
Often called "secret" questions and answers, security questions and answers are often used to recover forgotten passwords, or as extra security on top of 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. 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.
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.
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:
- "What is 1+1?"
- "What is your username?"
- "My password is [email protected]$p1N"
Black Box testing and example
Testing for weak pre-generated questions:
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.
Testing for weak self-generated questions:
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.
Testing for brute-forcible answers:
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.