The Failure of Security Questions

MIT's Technology Review author Robert Lemos recently tackled security questions as a method of password retrieval or resets. We've all seen these before - often a small number of fixed questions that have predictable answers. I wrote about them from a user perspective back in 2008 - The Problem With Security Questions - And An Easy Solution, where I discussed using a password safe utility and using answers unique to each site.

Lemos points out that research found that "answers that require only a little personal knowledge to guess should also be considered unsafe" and that "Of people that participants would not trust with their password, 45 percent could still answer a question about where they were born, and 40 percent could correctly give their pet's name, the researchers found."

Your pet's name is likely in your Flickr photo stream, or your email inbox. Your co-workers likely know your favorite sports team, your favorite color may be easy to guess from your fashion choices, and your pet and your significant other may be conversational topics that they would rememember - making many security questions useless.

Many security questions are less than creative, and worse, because they're intended to be something that everybody can provide an answer for, they're likely to be something that others also know or can find out from easily accessible records.

• What is your mother's maiden name?
• What is your father's middle name?
• What is your favorite sports team?
• What is your favorite color?

Most users proceed to use actual answers to these, meaning that the answers are easy to find in today's connected, database driven world of available information. How hard is it to go from a first name, a last name, and a geographic location to a user's personal details? Not that difficult. Parents names can be found in birth records, or you may be able to simply check their LinkedIn, Facebook, or other profile. Their favorite color or sports team can be found in similar places - and there are a limited number of guesses for most people.

Worse, family, friends, and acquaintances can often guess their way into such sites. Security staffers will tell you stories of disgruntled spouses logging into their partner's accounts using the facts that they know about the person to reset their password.

Many sites handle this with an email based password send capability - which shrdlu notes that he simply uses every time he visits the site so that he doesn't have to remember the site's password. I'm sure many of the rest of us have developed similar bad habits - and, of course, if you can get passwords sent via email, anybody who takes over your email account needs only visit those sites and request a password reset to take over those accounts too.

But security questions serve a very useful purpose, particularly for sites that have a large number of users, or who have users who may use the site only infrequently. They're a somewhat reasonable way of allowing users to have the ability to reset their password, and they push some responsibility to those users to keep their security questions difficult. The problem remains that without better options, users often create a back door into their account.

So, what alternatives are there?

• Out of band methods, such as sending an SMS
• Multiple factor methods, such as
  
• Validate against another data point or preferably, data points
• Skip a reset method and have customer service deal with it
  

Of course, not having security questions can also be a problem for some sites - social engineering to get passwords reset has worked many times in the past too.

I'll keep my eyes open for clever ways to handle this problem, and, perhaps more importantly for ways to explain the risk model effectively to management.

Grossman's Unanswered Questions

Jeremiah Grossman, one of my favorite web application security bloggers, recently posed a few of his unanswered questions - here's my take on a few of them, but be sure to read the comments thread. Anton Chuvakin's note that "firewall + website = web application firewall" in the minds of some rings true after my own experiences with compliance efforts.

1. Do people trust QSAs who consider PCI-DSS 6.6 met if their organization only uses a network vulnerability scanner with a few web application security checks?

For those not in the know, a QSA is a "Qualified Security Assessor" - a PCI approved assessor. PCI-DSS 6.6 (updated detail) says that you can use any of the following:

1. Manual review of application source code
2. Proper use of automated application source code analyzer (scanning) tools
3. Manual web application security vulnerability assessment
4. Proper use of automated web application security vulnerability assessment (scanning) tools

The problem that Grossman points to here is that some vendors will use a vulnerability scanner that doesn't provide deep software analysis capabilities - using Nessus instead of WebInspect, for example. My answer here is a firm "No". The capabilities found in full featured application vulnerability scanning tools are far more advanced than those found in most standard host vulnerability scanners. Vendors like Qualys are expanding their capabilities here, and other vendors are or have already. My answer will likely change as these features become increasingly more capable, but for now unless the QSA explicitly explains it, this doesn't appear to be the right solution.

Does this mean that organizations without internal technical expertise won't take a QSA's analysis at face value? Not at all. One of the major reasons that QSAs exist is because organizations need or want 3rd party assessments, and they trust those assessors to help them meet their PCI requirements.

3. As a result of economic downturn, what notable security projects are being cut from last years budget?

Training is being slowed down, and colleagues at other organizations note that they are cutting major initiatives - SIM/SEM technology, new IDS/IPS deployments, and other major hardware and software purchases are being delayed or are being re-scoped to highly critical areas. They're also getting more push to build internally.

The number of vendor calls, and the aggressiveness of those vendors is also increasing. I'm fielding more cold calls, and we're seeing things like the quick Google AdWord snap-ups following High Tower's demise.

I'm looking at the pullbacks as an opportunity - the frenetic pace of security device and technology deployment over the past few years has resulted in a wealth of existing information that frequently isn't as well leveraged as it could be.

5. Will secure code purchasing standards lead to secure code?

Sadly, no. I've seen some efforts along these lines, but I think that we'll see more success by putting testing tools into the hands of developers, as well as greater organizational maturity - secure code re-use for example.

As penalties for security issues become a more frequent topic of contractual negotations, this may begin to change. I've been advocating such a change in my own organization for a while.