Difference between revisions of "Choosing and Using Security Questions Cheat Sheat"
(More minor additions.)
|Line 1:||Line 1:|
= Introduction =
= Introduction =
Revision as of 10:04, 15 September 2012
- 1 DRAFT CHEAT SHEET - WORK IN PROGRESS
- 2 Introduction
- 3 The Problem
- 4 Choosing Security Questions
- 4.1 Steps
- 4.1.1 Step 1) Decide on Canned Questions vs. Create Your Own Questions
- 4.1.2 Step 2) Review Any Canned Questions with Your Legal Department or Privacy Officer
- 4.1.3 Step 3) Insist on a Minimal Length for the Answers
- 4.1.4 Step 4) Consider How To Securely Store the Questions and Answers
- 4.1.5 Step 5) Periodically Have Your Users Review their Questions
- 4.1 Steps
- 5 Using Security Questions
- 6 Related Articles
- 7 Authors and Primary Editors
- 8 Other Cheatsheets
DRAFT CHEAT SHEET - WORK IN PROGRESS
This cheat sheet provides some best practice to follow when choosing and using security questions to implement a "forgot password" web application feature.
There is no industry standard either for providing guidance to users or developers when using or implementing a Forgot Password feature. The result is that developers generally pick a set of dubious questions and implement them insecurely. They do so, not only at the to their users, but also--because of potential liability issues--at the risk to their organization. Ideally, passwords would be dead, or at least less important in the sense that they make up only one of several multi-factor authentication mechanisms, but the truth is that we probably are stuck with passwords just like we are stuck with Cobol. So with that in mind, what can we do to make the Forgot Password solution as palatable as possible?
Choosing Security Questions
Most of us can instantly spot a bad "security question" when we see one. You know the ones we mean. Ones like "What is your favorite color?" are obviously bad. But as the [Good Security Questions] web site rightly points out, "there really are NO GOOD security questions; only fair or bad questions".
The reason that most organizations allow users to reset their own forgotten passwords is not because of security, but rather to reduce their own costs by reducing their volume of calls to their help desks. It's the classic convenience vs. security trade-off, and in this case, convenience (both to the organization in terms of reduced costs and to the user in terms of simpler, self-service) almost always wins out.
So given that the business aspect of lower cost generally wins out, what can we do to at least raise the bar a bit.
Here are some suggestions. Note that we intentionally avoid recommending specific questions. To do so likely would be counterproductive because many developers would simply use those questions without much thinking and adversaries would immediately start harvesting that data from various social networks.
Step 1) Decide on Canned Questions vs. Create Your Own Questions
Believe it or not, there is a certain merit to allow your users to select from a set of several "canned" questions. We generally ask users to fill out the security questions as part of their initial user profile and often that is the very time that the user is in a hurry; they just wish to register and get about using your site. If we ask users to create their own question(s) instead, they then generally do so under some amount of duress.
However, there is also some strong rationale to requiring users to create their own question(s), or at least one such question. The prevailing legal opinion seems to be if we provide some sort of reasonable guidance to users in creating their own questions and then insist on them doing so, at least some of the potential liabilities are transferred from our organization to the users. In such cases, if a user account gets hacked because of weak security questions (e.g., "What is your favorite sports team?", etc.) then the thought is that they only have themselves to blame and thus our organization is less likely to get sued.
Since OWASP recommends in the Forgot Password Cheat Sheet that multiple security questions should be posed to the user and successfully answered before allowing a password reset, a good practice might be to require the user to select 1 or 2 questions from a set of canned questions as well as to create (a different) one of their own and then require they answer one of their selected canned questions as well as their own question.
Step 2) Review Any Canned Questions with Your Legal Department or Privacy Officer
While most developers would generally first review any potential questions with whatever relevant business unit, it may not occur to them to review the questions with their legal department or chief privacy officer. However, this is advisable because their may be applicable laws or regulatory / compliance issues to which the questions must adhere. For example, in the telecommunications industry, the FCC's Customer Proprietary Network Information (CPNI) regulations prohibit asking customers security questions that involve "personal information", so questions such as "In what city were you born?" would likely not be allowed.
Step 3) Insist on a Minimal Length for the Answers
Even if you pose decent security questions, because users generally not putting a whole lot of forethought into answering the questions, they often will just answer with something short. Answering with a short expletive is not uncomment, nor is answering with something like "xxx" or "1234". If you tell the user that they *should* answer with a phrase or sentence and tell them that there is some minimal length to an acceptable answer (say 10 or 12 characters), you generally will get answers that are someone more resistant to guessing.
Step 4) Consider How To Securely Store the Questions and Answers
There are two aspects to this...storing the questions and storing the answers. Obviously, the questions must be presented to the user, so the options there are store them as plaintext or as reversible ciphertext. The answers technically do not need to be ever viewed by any human so they could to stored using a secure cryptographic hash (although in principle, I am aware of some help desks that utilize the both the questions and answers for password reset and they insist on being able to _read_ the answers rather than having to type them in; YMMV). Either way, we would always recommend at least encrypting the answers rather than storing them as plain text. This is especially true for answers to the "create your own question" type as users will sometimes pose a question that potentially has a sensitive answer. (E.g., "What is my bank account # that I share with my wife?")
So the main question is whether or not you should store the questions as plaint text or encrypted. Admittedly, we are a bit biased, but for the "create your own question" types at least, we recommend that such questions be encrypted. This is because if they are encrypted, it makes it much less likely that your company will be sued because you have some bored, rogue DBAs pursuing the DB where the security questions and answers are stored in an attempt to amuse themselves and stumble upon something sensitive or perhaps embarrassing.
In addition, if you explain to your customers that you are encrypting their questions and hashing their answers, they might feel safer about asking some questions that while potentially embarrassing, might be a bit more secure. (Use your imagination. Do we need to spell it out for you? Really???)
Step 5) Periodically Have Your Users Review their Questions
Many companies often ask their users to update their user profiles to make sure contact information such as email addresses, street address, etc. is still up-to-date. Use that opportunity to have your users review their security questions. (Hopefully, at that time, they will be in a bit less of a rush, and may use the opportunity to select better questions.) If you had chosen to encrypt rather than hash their answers, you can also display their corresponding security answers at that time.
If you keep statistics on how many times the respective questions has been posed to someone as part of a Forgot Password flow, it would be advisable to also display that information. (For instance, if against your advice, they chose a question such as "What is my favorite hobby?" and see that it had been presented 113 times and they think they might have only reset their password 5 times, it would probably be advisable to change that security question.)
Using Security Questions
Requiring users to answer security questions is most frequently done under two quite different scenarios:
- As a means for users to reset forgotten passwords. (See Forgot Password Cheat Sheet.)
- As an additional means of corroborating evidence used for authentication.
If at anytime you intend for your users to answer security questions for both of these scenarios, it is strongly recommended that you use two different sets of questions / answers.
It should noted that using a security question / answer in addition to using passwords does not give you multi-factor authentication because both of these fall under the category of "what you know". Hence they are two of the same factor, which is not multi-factor. Furthermore, it should be noted that while passwords are a very weak form of authentication, answering security questions are generally is a much weaker form. This is because when we have users create passwords, we generally test the candidate password against some password complexity rules (e.g., minimal length > 10 characters; must have at least one alphabetic, one numeric, and one special character; etc.); we usually do no such thing for security answers (except for perhaps some minimal length requirement). Thus passwords generally will have much more entropy than security questions, often by several orders of magnitude.
Security Questions Used To Reset Forgotten Passwords
The Forgot Password Cheat Sheet already details pretty much everything that you need to know as a developer when answering security questions. However, it provides no guidance about how to assist the user in selecting security questions (if chosen from a list of candidate questions) or writing their own security questions / answers. Indeed, the Forgot Password Cheat Sheet makes the assumption that one can actually use additional identity data as the security questions / answers. However, often this is not the case as the user has never (or won't) volunteer it or is it prohibited for compliance reasons with certain regulations (e.g., as in the case of telecommunications companies and [CPNI] data).
Therefore, at least some development teams will be faced with collecting more generic security questions and answers from their users. If you must do this as a developer, it is good practice to:
- briefly describe the importance of selecting a good security question / answer.
- provide some guidance, along with some examples, of what constitutes bad vs. better security questions.
You may wish to refer your users to the [Good Security Questions] web site for the latter.
Furthermore, since adversaries will try the "forgot password" reset flow to reset a user's password (especially if they have compromised the side-channel, such as user's email account or their mobile device where they receive SMS text messages), is a good practice to minimize unintended and unauthorized information disclosure of the security questions.
Security Questions As An Additional Means Of Authenticating
Authors and Primary Editors
Kevin Wall - kevin.w.wall[at]gmail com
OWASP Cheat Sheets Project Homepage
Developer Cheat Sheets (Builder)
- Authentication Cheat Sheet
- Choosing and Using Security Questions Cheat Sheet
- Clickjacking Defense Cheat Sheet
- C-Based Toolchain Hardening Cheat Sheet
- Cross-Site Request Forgery (CSRF) Prevention Cheat Sheet
- Cryptographic Storage Cheat Sheet
- DOM based XSS Prevention Cheat Sheet
- Forgot Password Cheat Sheet
- HTML5 Security Cheat Sheet
- Input Validation Cheat Sheet
- JAAS Cheat Sheet
- Logging Cheat Sheet
- .NET Security Cheat Sheet
- Password Storage Cheat Sheet
- Pinning Cheat Sheet
- Query Parameterization Cheat Sheet
- Ruby on Rails Cheatsheet
- REST Security Cheat Sheet
- Session Management Cheat Sheet
- SQL Injection Prevention Cheat Sheet
- Transport Layer Protection Cheat Sheet
- Unvalidated Redirects and Forwards Cheat Sheet
- User Privacy Protection Cheat Sheet
- Web Service Security Cheat Sheet
- XSS (Cross Site Scripting) Prevention Cheat Sheet
Assessment Cheat Sheets (Breaker)
Mobile Cheat Sheets
OpSec Cheat Sheets (Defender)
Draft Cheat Sheets
- OWASP Top Ten Cheat Sheet
- Access Control Cheat Sheet
- Application Security Architecture Cheat Sheet
- Business Logic Security Cheat Sheet
- PHP Security Cheat Sheet
- Secure Coding Cheat Sheet
- Secure SDLC Cheat Sheet
- Threat Modeling Cheat Sheet
- Web Application Security Testing Cheat Sheet
- Grails Secure Code Review Cheat Sheet
- IOS Application Security Testing Cheat Sheet
- Key Management Cheat Sheet
- Insecure Direct Object Reference Prevention Cheat Sheet
- Content Security Policy Cheat Sheet