“Secret” Questions
I hesitated to write this, but the question has come up several times recently, so here you go anyway.
I don’t like secret questions for password retrieval. You’ve seen these, I’m sure: when you create an account somewhere, you’re presented with a list of questions to choose from and answer. The idea is that if you lose your password, if you answer the question correctly you can reset your password. Classic questions include mother’s maiden name, pet’s name, favorite song, that sort of thing.
You see secret questions because they are cheap and easy. If a customer can self-assert and reset their own password without getting someone on the phone — or if it’s a web site for which you’ll never get any help anyway — that’s a Good Thing, right? The downside is that secret questions reduce the security of passwords. (Passwords themselves are broken, as even the New York Times reports, but that’s a story for another day.)
When passwords can be retrieved or reset as the result of answering “secret” questions, answers to those questions are essentially passwords themselves. Weak ones.
Let me say that again, because it’s important and not everyone pays attention the first time. Answers to “secret” questions are weak backup passwords.
Answers are not held to the same password policies that the actual passwords are. Many systems nowadays make you jump through all sorts of hoops to have a certain complexity to your password, often enforcing a mix of letters, numbers, and punctuation. This is important to prevent dictionary attacks, a brute-force technique in which attackers cycle through hundreds of thousands of possible words, plucked from dictionaries (a word like “snowball” or name like “Voldemort” won’t stand up long to attack). It is trivial and fast to crack most passwords.
Secret questions can often be answered in a single word, a word that would violate the password complexity policy but that is still allowed as the backup password.
Answers to secret questions are often trivially discoverable. It would not take a determined attacker long to find my mother’s maiden name, my home town, or the name of any of my pets. Not only that: they’re dictionary words. Dictionary words are weak passwords.
Questions may have a limited number of answers.
- Favorite color? Chances are good that most people will answer from just a handful of possibilities: blue, red, green, yellow…
- Year of birth? It’s a safe bet that there will be fewer than 80 possible answers, probably quite a bit fewer.
- Home town? Lots of people come from big cities like New York and Beijing.
When users can supply their own questions, chances are pretty good that they’ll choose poor questions, again with trivially discoverable answers. People are not good at choosing security questions. Not long ago I once walked through the office and asked a dozen coworkers what their security questions would be. The most common response? “Last four digits of my SSN.”
Four digits. I rest my case. You can argue that people could have lied, and I hope that some of them did. But seriously. Four digits.
You should also be concerned that if you allow users to create their own questions, you will inadvertently end up storing private or sensitive data (say, ahem, SSNs), which may violate your privacy policy.
The situation can be improved somewhat by well-chosen questions — NOT letting users choose their own — and perhaps using multiple questions, although something about that makes me uneasy. It’s far better to use something in addition to secret questions, such as demonstrated control of a resource: email, a cell phone, smart card, or fingerprint.
Password retrieval systems are often poorly designed and easily subverted. “Secret” questions are just one example. I have rarely encountered a password retrieval systems that lock accounts for repeated failed attempts in the same way that repeated failed logins do. Passwords are sent in cleartext emails, which is not just a problem by itself but also suggests that the passwords are stored in cleartext. Considering that we too often rely on just a password for authentication — a situation that has got to change — we should do better.
30 Aug 2008 Sam
Thanks for wasting my time. We already know this. I thought you had solution.
Sorry you wasted your time.
As I said at the outset, I hesitated to write this post, in part because of what may be perceived as the obviousness of the problem. But in the past couple months, I’ve had several conversations with developers to whom this is all completely new. A couple of those conversations happened just last week. So I decided to write it and wreak suffering upon the unsuspecting.
Solutions? Read those last two paragraphs again:
* choose good questions. Nope, no guidance on that right now.
* multiple questions, although that just adds a speed bump by making it a trifle harder to crack with brute force.
* Expect demonstrated control of a resource.
* closely related to that, multi-factor authentication, although man-in-the-middle attacks render it less than ideal.
* Lock accounts for failed password retrieval attempts, or at least treat them the same way as failed logins.
Silver bullet? No. Just small design considerations that make small improvements. I’m not trying to suggest a good password retrieval system in this post, although maybe I should another time.
My problem with my “secret question” is that instead of asking a question, it reads “Question: question”. so I do not know what to answer. I have tried all the answers I can think of but I have been locked out several times.
It’s worse than that. If I was a bad guy, I’d be loving the current exhibitionist trend on FaceBook and other sites, of the “25 things about me” which are FULL of secret question answers.
In fact, you could phish someone pretty easy with one of those…
1. Guess one of your “friends” bank.
2. Write down the questions you have to choose from when creating an account.
3. Insert into the “25 things ..” list.
4. PROFIT!!!