Kernel Mustard

How many places do you know of that ask for a security question? This is usually for times when you forget your username or password. GMail has one, your credit card has one, and in fact, tons of password-protected resources give you the opportunity to specify a security question.

The problems with security questions

In my view, this is bad. It’s obviously an increase in attack surface[1], if you’re thinking from the perspective of the attacker - every security convenience carries with it a security compromise. These questions provide a backdoor to your accounts, and it’s not clear that that’s such a good idea in the first place.

But beyond that, the questions and answers tend to be pathetic. How many accounts do you have (credit cards, bank accounts, etc.) that use your mother’s maiden name as a security answer? Think about how bad that is. In a large proportion of crimes, the victim personally knows the attacker. How many people do you know - family, friends, etc. - that know your mother’s maiden name? To how many of these people would you give a credit card in your name? Remember, they only need to know the name of one of your uncles or cousins on your mom’s side of the family. This is craziness.

OK, let’s assume you 100% trust your family and friends. Do you trust the rest of the world? Births and marriages are matters of public record (although some states do restrict access to these records). Any competent investigator should be able to find such a trivial piece of information.

The security of a system is only as strong as its weakest link. If you pick strong passwords but have a weak security question, the total security of your information is weak.

Characteristics of a good security question/answer pair

So, say you’re uncomfortable with using your mother’s maiden name, so you use an alternative security question. It turns out that this is not as easy as it looks. The characteristics of a good security question are similar to those of a good password, with some additional constraints:

1. The answer has to be hard to guess by brute force. what color are my wife’s eyes has only 3 common answers, so on average it’ll be guessed on the second attempt. Same goes for yes/no questions, true/false questions, and so on. Even the number of cents on my last tax return can be guessed on average in 50 guesses.
2. The answer has to be easy to duplicate precisely. If you’re typing the answer into a website, it’ll probably be compared character-by-character. Questions like What is the address of the house I was born in? are tricky - did you spell out street or the name of the state? Did you even include the state’s name? And so on.
3. The answer should be hard to find through alternative means. That means not using anything that is (or could become) public record. That’s another reason that the previous question (where you were born) is a bad idea.
4. As a corollary to #3, your friends and family should not be able to guess it. You wouldn’t give everyone (anyone!) your password; why would you give them your password’s backdoor? Things such as What is the name of my bigger cat? are answered to everyone you know every year in your Christmas cards.
5. It should be straightforward for you to answer. It’s better to write down passwords than to pick crappy passwords, but this particular one is worse than average to leave written down somewhere. You aren’t likely to remember to change your security question/answer very often. If it is discovered (including via alternative means), it’s as good as having no password on your accounts. Also, realize that you will probably never use this, so you won’t remember it very well three years later if you pick something arcane. Make sure the you three years from now will be able to deduce the answer to a question invented by the you of today.
6. For heaven’s sake, please don’t use sensitive information - don’t use the last four digits of your Social Security Number, for example, because that’s most of the randomness. And remember, unlike passwords, the answers to security questions tend to be stored in cleartext in databases for confirmation by telephone operators[2].
7. You should probably change your question and answer every so often. I’m not aware of any particularly good guidelines for this, but off the top of my head it seems like you should change your security Q/A about as often as the corresponding password. There are obvious arguments on both sides of this question; default to being secure.
8. Pick a question and answer that are secure enough for the resource you’re trying to protect. If it’s a hotmail account that you don’t care about at all, mother’s maiden name might be OK. But if it’s your brokerage account, pick something that reflects the amount of money in the account.
9. To the extent possible, don’t re-use security questions and answers across accounts.

Picking good security questions and answers

So, how DO you pick a security question and answer? Precisely what you do depends on how flexible the interface is. If the website or operator only knows how to ask for your mother’s maiden name, make something up. At least that way it’s not public record. If you’re going to vary the answer from site to site, be very certain that you can remember which answer to give years from now.

If you can pick from a list of questions, pick the least offensive question and, if it meets the criteria outlined above to your satisfaction, use it. Otherwise, revert to making something up. It might be wise to select mother’s maiden name as the question to remind yourself that the answer is made up. Also, remember, it may be better to not give away any of the information asked for.

If you can make up your own question, do so. Start by thinking very carefully about questions and answers that fit the profile above - things that are genuinely hard to answer for everyone else but are easy for you.

Make a list of things that you know that (almost) nobody else would know - things like your third grade teacher’s name, your 2005 adjusted gross income, what your parents would have named you had you been of the opposite sex - and NEVER give them away to anyone. Make as big a list as you can. Note that you don’t have to have these answers top-of-mind at all times; you just have to be able to go find them (with a high degree of precision and reliability) if needed. Remember, you need to find these answers years from now, when your memory is much worse!

Using these pieces of information, cobble together a list of precise questions that require you to combine these pieces of information in such a way that they’re not directly revealed. For example: What is the sum of your first phone number and the first numeric part of you grandparent’s address and the number of cents you received on your 2004 federal tax refund? If you’re a super-geek, you could even simply ask What is the SHA-1 of (your high school GPA times your rent payment)? By mixing and matching secrets and encoding them, you can come up with a wide variety of question/answer pairs without actually revealing much information.

This isn’t a foolproof scheme. There are cryptographic attacks, in principle, against the kind of obfuscation I am describing here. The purpose of combining pieces of information is just to make it harder to recover the originals; anything besides a cryptographic hash of a sufficiently long plaintext is probably more obfuscation than security[3]. But it probably will keep the person on the other end of the phone line from figuring out any of your secrets unless she or he is determined.

Remember: you don’t have to be able to come up with the answer off the top of your head. You just have to be able to reliably reproduce it in a reasonable period of time. Passwords are for convenience. Security answers can (should?) be inconvenient.

Summary

Determined attackers will defeat your security; that is axiomatic. Fortunately, there are few determined attackers in most people’s lives. Still, using your mother’s maiden name for anything important is equivalent to dead-bolting the front door while leaving the back door unlocked. And hanging open. With a big “Out Of Town” sign, in lights, on your front lawn.

[1] OK, that’s not quite how attack surface is conventionally used, but the concept is the same.

[2]. Strictly speaking, they don’t have to be, and in my opinion, they most certainly should not be, but that’s another story for another day.

[3] Consider the time it takes to brute-force a SHA-1 hashed version of the number of cents you got back on your tax refund. It would take an average of 50 digests of a 2-byte input, which in practice is instant.

The more complex the system, the harder it is to secure. Apple’s Mac OSX has had a capability called FileVault for a while now. The basic idea is that it encrypts your home directory and everything that lives in it, including mail, browser cache, private application state, and so on. It’d be the windows equivalent of encrypting HKEY_CURRENT_USER plus all the files in your user’s directory.

A hint posted recently to Mac OSX Hints shows a problem with FileValut and Mail that leads to an information disclosure in a very public place on the box (/tmp). You can argue about how bad this really is, but I’m more interested in the pattern here. It’s not enough that information be hidden in its final resting place; it has to stay hidden at all points along the way. This is why people worry about encrypting page files and protecting memory (which was part of the Orange Book C2 standard that Windows qualified for back in the NT4 days).

Spoofing CallerID is now trivial. Go sign up, via the web, for a trial VoIP account at one of the SIP wholesalers, and set up Asterisk. Pick whatever outgoing CallerID you want.

So, from now on, make sure never to build a system that uses the incoming CallerID as an authentication token. And, don’t believe what you see on your CallerID.

While I’m on the topic of security, I thought I’d do some math on PIN strength vs. password strength. Initially I had assumed that the entropy-per-character of PINs, which are generally only digits, would be worse than the entropy-per-characrer of full passwords. Now I’m not so sure.

PINs that are composed of digits, where each digit is equally likely, represent 3 1/3 bits per character of entropy, so an 8-digit PIN is 27 bits of entropy.

Passwords have a wider range of characters to draw from: A-Z, a-z, 0-9, !-), to take the easy set, although there are more. That’s 26*2 + 10*2 = 72 characters, or about 6 bits of entropy per character, for a total of 48 bits - or about 2 million times as many possibilities.

The problem with this analysis is that not all characters from the set of 72 are equally likely. In fact, good old fashioned English text has an astonishingly low 1.3 bits per character of entropy, according to Bruce Schneier in Applied Cryptography. That means your 8-character password is only good for about 10 bits of entropy, meaning it has 128,000 times fewer possibilities than an equivalent-length PIN.

Of course, it’s relatively easy to pick secure passwords if you are careful, with one effect being to increase the bits/character of entropy by consciously expanding the character pool to use more symbols. A well chosen password ought to have much more than 1.3 bits/character of entropy.

I don’t have any stats at my fingertips on the entropy/character that results from certain password complexity rules (mixed case, numbers, symbols, non-dictionary, etc), but I suspect that it should approach PIN-level entropy in even the worst cases, and can obviously go far beyond 3 bits/character if done well.

I’m playing a little loose with the concept of entropy here; there’s really a lot of theory behind this stuff. As usual, Wikipedia entry on information entropy is excellent, if a bit on the mathematical side.

Sometimes security-related concepts pop up in a non-security context. Legalese has a lot in common with code (particularly if you consider the perspective of Lawrence Lessig), so it’s fun to watch people try to find loopholes like this one:

It got little notice at the time, but Richard Stallman, the leader of the FSF (Free Software Foundation), said at the fifth international GPLv3 conference in Tokyo on Nov. 21 that the Novell-Microsoft patent agreement is not in violation of the GPL version 2.

Stallman, the primary author of the GNU General Public License (GPL), said, according to a transcript published by the FSF Europe, What has happened is, Microsoft has not given Novell a patent license, and thus, section 7 of GPL version 2 does not come into play. Instead, Microsoft offered a patent license that is rather limited to Novell’s customers alone.

Stalman is a programmer, and one of the best in the business drafted the language for the agreement.

Producing secure software, like producing bulletproof licenses, is a negative deliverable. It’s hard by definition.