Two posts in a day, I’m on a roll (well not really; most posts I complete the night before and read over again during the day, before publishing, when I am lucid and not splitting attention between what I am writing, an attention hungry five year old, my wife, and an affection demanding but otherwise clueless cat. This is one of the few posts I am actually composing while at work before I forget about it). Anyway, having just finished complaining to my coworkers about yet one more site that seems to be using stupid security questions for their forgot password functionality (not one of our company sites, we have pretty strict security standards regarding when questions are even acceptable and how they are implemented, generally stricter than this post pleads for) I feel the need to share some advice with the random folks that occasionally stumble in here.
There are several things to keep in mind when creating security questions, but mostly they should be easy for the customer to remember the answer to (and please use a tolower call on both the provided and stored answer before comparing people, I don’t want to remember which case I used) and very hard for an attacker to figure out. The number of websites that don’t get this right are staggering.
To start with the last criteria first, security questions should be hard for most attackers (I say most because if a close friend/family member is the attacker there aren’t very many questions that would meet the first criteria that the attacker either wouldn’t know or couldn’t find out). This means the question shouldn’t have a very limited possible answer set. “What is your favorite color?”- well lets try blue (apparently the color most likely to be a favorite in America. Good branding job democrats), red, black, pink, green, purple, grey and orange. We could go further in depth, but those are the most prefered colors in the US (I have no idea if it is a cultural thing, or if by extension the rest of the world shares a similar ordering) and cover the majority of the population. That can be brute forced very easily. Likewise questions along the lines of “How old were you when…”, “What grade were you in when…”, “What is your favorite movie genre” and so forth all easily brute forced because most people’s answers fall into a predictable and small set. Questions like these lend themselves very well to automated attacks hunting for credentials.
Questions that are easily publicly discoverable are also a bad idea even if they otherwise have a much larger brute force dictionary. Questions about a person’s family (father’s middle name, mother’s middle name, etc) can easily be discerned through the various family tree websites. Questions that could easily be gleaned off of a person’s myspace/facebook/whatever page are also a bad idea since most users of these sites use their real names and are easily found doing a google (or yahoo or live if you swing that way) search. Most profiles on social sites list favorite band, book, tv show, etc, but also things like high schools and colleges. Using questions that are easily publicly accessible makes it easy for attackers to compromise the system with nothing more than google searching for details about a known user (they don’t work great for blind attacks though).
As for the other criteria, that the answer should be easy for the user to remember, this acts more as a constraint for how esoteric a question can get (if they have to think about the answer when filling out the field initially, they probably won’t recall what they said when prompted) than as a genuine security concern. If the user can’t consistently answer their own security questions the feature is pretty pointless. One of the things to keep in mind is that even general easy to come up with answers can eventually become hard to remember. Current “favorite whatever” questions are susceptible to the user changing their mind. For example, a person’s favorite television show tends to change over time, and they shouldn’t be forced to recall what their favorite whatever at the time they signed up for an account.
So what are good security questions? Here are a couple I have seen and liked:
- Who was your best friend in kindergarten?
- Who was your first significant other (though not so great for people who married their first SO)?
- Where did you and your current SO go on your first date?
- What was the name of your first pet (I actually like when this is more specific to cat or dog, since many people had both simultaneously; it is easier to recall the answer)?
- What did your mom/dad do for a living when you were born?
Not all of these questions apply to everyone but they have the benefit of being fairly hard for a stranger to discover without being overly hard for the person to remember. As mentioned though, they will not apply to everyone, which is why the user should be presented with a list of secret questions and are allowed to pick a subset for their own security questions. The list should be broad enough that everyone should be able to find a couple applicable questions.
Venturing further there are other ways to improve the forgot password functionality, such as requiring a user to answer multiple secret questions to further mitigate against data mined attacks. Ultimately such questions will still likely be susceptible to attacks by close acquaintances and disgruntled family so developers need to weigh the risks and business requirements when deciding how strict to be with the functionality.
So please various web developers, stop using weak questions, and please for the love of whatever you hold dear, don’t display the password to the screen or allow a new password to immediately be set after the questions were answered. Emailing existing passwords is also not a great idea. Setting a new random temporary password (by temporary I mean with a timeout as short as possibly can be acceptable by your application sensitivity and business cases) that gets emailed and requires the user to change on first login is probably a good practice. For very sensitive applications the widespread “forgot password->secret question” paradigm might not even be strong enough, nor am I advocating this paradigm over another. I am simply asking that if it is what a web developer chooses that they can take some steps to make it less vulnerable than I typically see.
~ Joshbw