Insecure Implementations Of Challenge Question Answers (CQA) For Password Resets

An example of C/Q
setup for on-line banking

Challenge Questions Answer (CQA)are widely used in web sites as a form to validate the user during un-authenticated transactions such as password resets, user name resets as well as extra authentication factor besides passwords during logins. The problem with CQA is the degree of freedom given to the implementation leaves a lot of room to deliver in-secure validation. Some of you might be familiar for example with the Gov. Sarah Palin's yahoo email hack via yahoo email password reset. It was due because yahoo email reset validate users with questions that can be easily guessed from public profiles such as birthday, country of residence and postal code. This is from implementation. Gov Palin as any user of yahoo email is allowed to select easy questions among a list, such as "Where did you first meet your spouse". This, again is implementation problem, for a public person like she is (but this applies also to users of Facebook and social sites) the answer to that question could be easily guessed (Wasilla high). The other control on yahoo email reset is to validate a secondary email address associated with the account for which hints are given. Apparently this was not set up. The attack that was highly publicized that time simply highlights that even companies like yahoo still do not get how to get email password reset securely implemented.

This example underlines a problem of 1) user awareness on which CQA to choose, 2) Force user to choose CQA that are not easy to guess, for example asking DOB (date of birth) besides being considered Personal Identifiable Information is a bad question where asking a user to choose a date that is memorable may be better. The concept that CQA need to learn also is the one of entropy that is not easily guessable with different means, besides by public profile searches is also by the length of the question that at minimum has to be of a certain number of characters. In this context if my favorite town is New Your City, NYC cannot be entered because three letter city names are not allowed.

In the case of financial web applications, good secret questions are the ones that require specific shared knowledge between the user and the authenticator such as shared knowledge of events (e.g. the last time you make a payment) or specific knowledge of data (e.g. the exact amount of customer's monthly mortgage payment).

To improve entropy of the shared secret, you can prompt the user to answer different shared secrets by randomly choosing them from a previously set of pre-registered answer/questions.

The mortgage question that is not usually deducted from public records (obviously does not include dumpster diving) is better than a question such as most favorite movie or soccer team, or the high school where you dated your husband/wife. But also this is not immune from attacks a typical Monday morning dumpster dive may reveal the others or a simple call to the mark with a refinance question to capture in your example the "monthly" mortgage payment.

The emphasis I am making is that the CQA have to be shared secrets between the authenticator and the authenticatee. An example can be to validate time and information data that is shared secret between the user and the Bank such as when you visited the ATM and how much money you withdrew. Of course these requires query data sources and are not easy to implement.

Ideally web site architects that implement this controls they need to be guided on how to implement CQA securely in the application uses cases of password and userID reset as well as a form of "extra" factor of authentication besides passwords. The concept of what constitutes a good non-guessable CQA should be covered as well as how to implement the password reset security.

A good guideline for implementation of CQA is OWASP Using Secret Questions Page

You can also test if you password reset is done security by looking at the password reset section of the OWASP testing guide.

For example once you had the password rest after CQA validation, a good practice is to deliver the one time temporary password out of band to the user with a different channel such as SMS. This will allow for identification of the user via a call back and also another layer of defense against someone attacking the email channel during the outbound password delivery such as in the case of Man In The Middle Attacks.

In the case when CQA are not pre-registred such as in the case of validation of question based upon demographic information that is known about a user from Knowledge Based Authentication system, ideally you want to consider this only to validate low risk application function since the degree of security of these questions is one notch lower then CAQ based upon shared secrets and two notch lower than passwords. This is to consider also in user validations that fall back to KBA from failing to validate a password at login as security expert Bruce Schneider points out in The Curse of the Secret Question . It would be ok if I am falling back from low risk authentication control such as one that uses IP for authentication to another low risk control such as KBA.

The best use case for using KBA CQA is in the case of a user applying for an on-line account for which no previous information is known about the user. It is better than validate the user with information that is sensitive and can be phished to attack other channels such as for example validating the user with ATM PINs or with PII such as SSN. A KBA with a rich set of CQA such as group of 20-25 questions selected ramndonly is also more difficult to phish than a set of 2,3 CQA (provides better entropy)