Questions about Questions.
One of the security measures we are all becoming overly familiar with is the Password Reset Security questions used today. So just what is a good way to use security questions? Recently I was asked to put together some recommendations around the use of Security Questions for resetting passwords.
There are two methods commonly in use at this time
· Pre-Canned Questions (PCQ)
· User Defined Questions (UDQ)
Pre-Canned Questions
From a usability perspective the Pre-Canned questions are a bit easier to deal with because the user only has to supply an answer, rather than come up with a question, and the answer. However, from a security perspective, Pre-Canned questions are not as secure as User Defined questions. Most of the questions in these Question Based Identification systems are well known: What is your mother’s maiden name, What is the name of your first pet, What is the name of your first school, etc.
The problem with most PCQs is that they are designed around information that is either public domain or easy to social engineer out of someone. There are some organisations that have taken the PCQ further and created very obscure questions that are not the common ones in most default Question Based identification system. They ask information that hopefully only the real user knows, and that isn’t in the public domain somewhere. However, even with these, close friends or astute attackers can still identify the answer such as ‘Who was the first person you kissed?’.
There is even some concern in conspiracy circles that the PCQ option is designed to collect demographic information that you would not otherwise normally give to a company.
Implementation
The implementation is quite easy for PCQs. There are simply 1-* questions that are defined and stored as part of the application meta-data. During account creation the user selects the question(s) they want to have as their secret identification, and then supply an appropriate answer. The answer should be stored as salted hashes, not the plain text answer to the question.
User Defined Questions
User defined questions are an order of magnitude more secure than PCQs. The reason for this is that the attacker now does not know the kind of data they have to collect before-hand. While they may still be able to discover the questions that the user defined by simply requesting a password reset from the account, they will hopefully then have to try and discover answers that can only be obtained by asking the legitimate user themselves.
In some circles UDQs are considered less friendly from a usability perspective. After all, now the user has to think up a question as well as an answer. It is expected that the answer to the question should be easy for them to come up with though. There is also the possibility that when presented with the request for a question, that the user enters something they’ve seen on other sites such as ‘What is your mother’s maiden name?’. At this point though, the strength (as judged by how easy it would be to determine the answer to the question) is in the hands of the user and it is their choice, and their risk if they decide to use a question with a publicly researchable answer.
Implementation
The UDQ approach requires the ability for the system to accept and store the questions the user enters. Normally the questions would have to be stored in plain text, or through reversible encryption. The latter being the recommended option. The answers however would be stored as salted hashes of the actual answer the user entered during account creation.
Asking the Questions
Once a choice has been made about which type of questions to use, asking them is another matter.
There are several ways to ask the questions:
1. Ask a single static question which was defined or selected by the user during account creation
2. Ask a single question randomly chosen from a battery of questions defined or selected by the user at account creation.
3. Ask more than one question randomly chosen from a of battery of questions that was defined or selected by the user at account creation
Option 1 is the worst from a security standpoint as the attacker only has to obtain one piece of information. But it is the best from a usability and system design standpoint as the user only has to supply one answer, or question/answer at account creation time. It also remove the random question chooser from the design of the application.
Option 2 is a better choice from a security perspective. However, the user has to define multiple answers or question/answer pairs at account creation, and the system has to store multiple answer or question/answer pairs for each user.
Option 3 is the best from a security standpoint. This introduce the most problems for an attacker to deal with. Not only do they have to know all the possible questions that will be answered, but their answers too. This option represents the worst usability though. Not only do users have to define 1-* answer or question/answer pairs as in option 2, but they have to enter multiple answers during the reset process. From a system implementation perspective it is not much more complicated to implement than Option 2.
In either case, the most important part about Question Based Identification is that the answers, and potentially the questions themselves, be something that is not publicly available (i.e. driver’s license number), and that is very difficult to social engineer (i.e. TFN, SSN ).
Alternatives / Additions
Some sites prefer to bypass questions altogether and send the user a link to a secure reset web site instead. This is acceptable, but you are relying on the fact that the person requesting the reset, is the only person able to access that email account and that they are the legitimate owner of the account.
In order to have multiple levels of authentication you might want to extend the question based system to implement an emailed link to a secure web site for password reset after asking the security questions. So in this case, once the user answer the security question(s) appropriately, they are emailed a life-limited link that will take them to a secure site where they will enter a new password.
*-Never ever send usernames and passwords to a user through email
Email them a life-limited link to a secure (SSL/TLS) site to enter their new password instead.
Just note that the email notification can be problematic if the link email is caught in a spam filter, or if the users is shopping remotely and cannot access their email at the time. (not everyone has web based email or knows how to use it)
Recommendations
Based on a security first perspective, tempered with usability, Option 2 discussed above is preferred. Option 3 is the best security choice, but it is not as usable. Option 1 is not recommended.
Option 2 provides the added security of using UDQs, with decent usability by asking 1 question at a time during reset. The user only has to define multiple questions and answers during account creation. If there is text on the page explaining that this is done to protect their money, they should be accepting of it.
When option 2 is combined with an Email Link, it provides a secure reset capability. It would be a question of usability and confidence in the requestor being able to get to their email during the password reset process.
Best Practices for Users around Security Questions
When you are asked to either define these kinds or questions, or just define the answers to standard questions...be creative.
The most common problem with a lot of these systems is that they ask information that anyone can discover with a quick Internet search, or by watching the victim for any amount of time. For example, it would be very easy to discover my mother's maiden name. So when presented with this kind of question, supply a totally nonsensical answer.
Q: What is your mother's maiden name?
A: Purple Sunday
Be patient and creative if a site asks you to define multiple questions and their answers. Remember, this is to prevent someone from compromising your account. It may seem a bit frustrating to have to go through this, but consider the alternative. If someone was able to easily guess this information, and reset your password...they can do whatever YOU can do on your account.