I have two locks on my door. One of them is integrated with my doorknob. The other is a deadbolt that is a little heavier-duty. I’m glad that IT security practitioners didn’t design my locks, because they probably would have expected me to use a key for one of them and a bobby pin for the other.

Let me explain.

Passwords are well known to be a terrible solution. Basically, the idea of a password started at MIT as a way to keep nosy students out of records (source); rather than question whether passwords were a good solution to the problem (keep people out of private information), it became a de-facto standard. We’ve been living with them ever since. Passwords are such a problem now that we all have so many credentials that companies sell password managers so we don’t have to remember them! Of course…. that service still requires a password.

Ok, so passwords are not an ideal solution - easy for computers to guess, hard for people to remember (xkcd). So what if we introduced a second factor that was hard for computers to guess, and easy for people to remember?

Enter the security question. Theoretically, security questions are easy to remember and static facts about the user in question; commonly a school the user went to, the name of a relative, the birthdate of a sibling, etc. These things have meaning and value in everyday life, which makes them great for recall.

But wait. What about social engineering? You know, the practice of bad actors attempting to gather information from an unsuspecting user with the goal of infiltrating a private system masquerading as the victim? Because these security questions are facts, and they seem innocuous enough alone, people do not protect this information (looking at you, viral facebook images).

So to recap - passwords are hard to remember and computers can guess them easily (relatively). Security questions are easy to remember and easy for would-be attackers to obtain. So what should our solution be?

Obviously, to leading IT security best practices, the solution is to answer your security questions with intentionally false information (source, source, and source).

That’s right. In order for a security question to be fully effective, you need to answer it incorrectly on purpose. And then you must proceed to answer it incorrectly the same way every time.

One of the financial institutions I transact with uses security questions. The account in question has been open for more than a decade. Over a decade ago, I answered my security questions in light of these best practices. And now, I absolutely cannot remember the answers! I know I answered them “wrong” but I don’t know what “wrong” answer to give the system. But this is what must be done in order for security questions to work as designed.

What a broken concept.

Couple all this with increasing amounts of research that show that security questions do not really increase the security of a system in any appreciable way, and you’ll start to understand my point.

So what to do? My little blog post is not going to move the needle for most people (especially IT security professionals who stick their neck on the line whenever they come out against the prevailing wisdom of the day). Using a true second-factor application or hardware key, as well as using biometrics seem like promising options, but uptake on these has been slow, and they all suffer from their own issues as well. Even still, there are some clear directions for making passwords and authentication generally less user-hostile.

I only wish my financial institution would listen to the advice.

Until then, you can find me at my back door, trying to jimmy it open with anything besides the key.