Parola secreta?

Using Secret Questions
To help verify a user's identity in the case of a lost password, many Web applications use secret questions. By answering a pre-selected question, a user can demonstrate some personal knowledge of the account owner. A classic example is asking to provide a mother's maiden name.

Answering secret questions requires some knowledge of the user account, but secret questions break all the rules for strong passwords and have some significant weaknesses:


 * An attacker can sometimes discover the information with little research;
 * The answer to the question is usually a fact that will never change;
 * Users reuse the same secret questions and answers across multiple Web sites;
 * Someone close to the individual could know the answers to many of the questions;
 * People rarely change their secret questions;
 * The answers are often case-insensitive and usually contain a limited character set;
 * Some questions have a limited number of answers; and
 * With some questions, many people will have the same common answers.

Secret questions usually ask for an obscure fact that hopefully only the account owner would know and supposedly would never forget. Many Web sites assume that the user providing the answer to the question is sufficient to identify the user. However, many secret questions ask for facts that anyone could discover with little research. To make things worse, if someone discovers this information, you cannot just change a fact from the past.

Countless Web sites provide great tips on avoiding easily guessed passwords but then turn around and ask for a pet dog's name or what city you were born in to answer a secret question.

Even if an attacker knows nothing about the target user, the nature of secret questions limits the possible range of answers. For example, consider the questions and ranges of answers shown in Table 1. As the table shows, many secret questions have so few possible answers that a brute-force attack against these secret questions is completely feasible. To make matters worse, some Web sites fail to detect or prevent brute-force attacks against secret questions. For years, security experts have told people to avoid using pet names, family names, or dates in passwords, but secret questions go directly against that advice.

The key to properly using secret questions is to understand that they should never be the equivalent of a password. You should only use them to initiate a password reset, to prevent anonymous attacks against the password reset process. Providing the answer to a secret question should never be enough to validate a user, but combined with other factors, such as having access to the user's e-mail account, secret questions can be effective in helping to identify a user.

The greatest threat with secret questions is that the answer is usually fixed and an attacker can sometimes discover this information through research. Because there is usually a limited set of answers to secret questions, they are also vulnerable to brute-force attacks. Finally, secret questions are usually ineffective against attacks by people close to the user. Individuals such as ex-spouses, once-close business associates, or wayward teenage children may have sufficient information and sufficient motivation to break into a user's account.

Designing Secret Questions
The key to successful secret questions is to clearly define their role as just one part of the password retrieval process. They prevent password resets without some personal knowledge of the user. Design the system to be flexible with secret questions and answers, allowing users to disable secret questions or requiring a telephone call for final confirmation. Another effective technique for security-sensitive Web applications is to allow or require users to answer more than one secret question.

Avoid allowing users to select their own questions, since most users are not qualified to select strong enough questions. Sites that allow users to select their own secret questions end up with insecure questions such as:


 * What year were you born?
 * What is your password?
 * What is the capital of Georgia?

Select effective questions, carefully considering the possible range of answers as well as the likelihood of common answers. Use unique questions, and try to avoid subjects that return short, one-word answers. Also, try to avoid questions that others commonly use, such as mother's maiden name, pet name, or high school. But keep in mind that you should ask questions that users will always answer the same way.

Establish a large list of questions, but provide a short, random list from which users can select their own questions. For users more concerned with security, you might want to provide an advanced option to select from a larger list of secret questions.

If the user provides a predetermined number of incorrect answers to the security question, you might not want to return an error, but instead send the user an e-mail explaining that he or she answered incorrectly. This will prevent brute-force attacks against the secret question process and alert users to a possible attack against their accounts.

Here are some examples of effective secret questions:


 * What is the first and last name of your first boyfriend or girlfriend?
 * Which phone number do you remember most from your childhood?
 * What was your favorite place to visit as a child?
 * Who is your favorite actor, musician, or artist?

Remember that secret questions by themselves are not as secure as a password and you should never use them as a password equivalent. Treat secret questions as just one part of a secure password recovery system. Allow users to change their secret questions and answers if necessary build code to detect brute-force attacks against secret questions. Design your questions so that there are many possible answers and that few people will select the same answers.

Secret questions are not as secure as passwords but they do have their place. Used appropriately, they can strengthen your web site security. But used incorrectly they can quickly lead to compromised user accounts.

Table 1: Secret Questions and Ranges of Answers
Mark Burnett (mburnett@xato.net) is an independent security consultant and author who specializes in Windows and web server security. He is an IIS MVP and author of Hacking the Code (Syngress Publishing).

Hacking the Code (www.hackingthecode.com), written by Mark Burnett, is a unique book that walks you through the many security threats facing ASP.NET web developers. The book provides concise solutions, code examples, and security policy to address each of these threats threat.