Personal Security Questions Are Bullshit

I hadn’t flown on United Airlines for a long time. But in August 2016,  I booked a flight with them and tried to manage it via my United.com account. That was a mistake. Instead of providing real, useful security (like multi-factor authentication or Touch ID on the iPhone app), United insisted that I set up five personal security questions before I could access my account. All I needed to do was check in, but United decided they’d like me to do a pointless security dance for them.

United Airlines security qeustions

You’ve probably run into these types of questions before. They’re a well-intentioned (but horrible) form of security which tries to confirm your identity by asking you questions about yourself. Since the service you’re trying to use doesn’t know much about you, you have to choose the questions and provide the answers ahead of time. The questions range from the simple  – “What’s your favorite color?” – to the esoteric – “Where did your grandparents meet?”.

It’s understandable. These services have decided security questions are useful, so they’re very insistent that you answer them when trying to access their service. Unfortunately, they usually also insist that you set up the questions and answers before actually getting to use (or try out) the service they provide.

In my case, I needed to get the boarding pass for my flight. But United wouldn’t let me access my account till I’d set these questions up. In an attempt to avoid this nonsense, I gave up on their website and downloaded their app—which will probably be seen as a win by their marketing department. But that forced me to do the same thing, only on a small screen with no physical keyboard.

 

United Airlines app security questions

Here’s a challenge: try setting up five security questions on your phone without wanting to smash it. I couldn’t. So I checked into my flight without even logging into my account. It’s been months since this episode and I still have not answered the questions, and I don’t ever intend to.

Personal security questions are not only bad UX design; they’re an outdated security mechanism. They’re bullshit and I don’t like them. Here’s why.

User Experience: Security Questions Wreck It

Security questions predate the web and the Internet by many decades. A speech from 1906 mentions an early use of “mother’s maiden name” to prove identity:

The card record embraces “Birthplace”, “Residence”, “Mother’s maiden name”, “occupation”, “age.”  … Indeed, beyond the desirability of “residence” as a means of communication, if needed, the record “Mother’s maiden name” is in itself a strong test of identity. Attempted withdrawals other than by members of the same family or by someone familiar with the signature through association are rare (I do not recall any attempt to withdraw from a lost book), and whilst the ordinary recording of Father’s or Mother’s given name can be answered by almost anyone knowing the family, the Mother’s maiden name is rarely known. On opening an account the depositor is often unprepared for this question.

But why have they survived so long?

A password is the first line of defense for an account. But alone they can’t be relied on because people are notoriously bad at creating good, strong passwords. And even when we do choose and remember a strong password, it is just a single lock on an account. To reduce the likelihood that someone can break into an account, we provide multiple locks. This is where security questions come in.

But while security questions were state of the art in 1906, we have much better technology and processes today:

  • Text messages containing links or multi-digit codes.
  • Login links sent to predetermined email addresses.
  • Apps which ask you to approve a login by providing a multi-digit code
  • Physical USB keys which authenticate their bearer.
  • Fingerprint verification, such as Apple’s Touch ID.

All of the above are more effective, and less intrusive, than security questions.

Demanding the setting and answering of security questions not only interrupts the user, preventing them from doing what they signed up to your service for in the first place but often annoys them. Given how fragile user engagement can be, as a developer, do you really want to put a giant roadblock in the way of your user using your service?

But hang on. Isn’t security more important than user experience?

Much of the computer science community harbors a long-standing belief that more security must mean more inconvenience. Two locks are twice as secure as one lock, but also take twice as much effort to operate. However, that is no longer true.:

  • Encrypting web communication with SSL is inconsequential to the user’s experience, but greatly improves security.
  • Hardware solutions like Apple’s Touch ID are simple and provide a better user experience than alternatives like PINs and passwords.
  • Command line users may remember the old telnet protocol, which allowed users to remotely login to servers but was highly insecure. The newer ssh (secure shell) protocol replaced it, providing better functionality and an improved user experience (using encryption keys to authenticate automatically rather than requiring typing passwords each time)

Improving security does not mean you need to make the user experience horrible. You no longer have to risk alienating your users in order to make their accounts more secure.

Which leads us to another question. Do security questions actually help improve security? No.

Security: Security Questions Aren’t Secure

Catch-22: You can answer security questions honestly, but if you have any social media presence, attackers may be able to easily figure out the answers to your questions. Do you share photos of your pets or vacations on Instagram or Facebook? Pin photos of your favorite cars on Pinterest? Is your family tree in Ancestor.com? If it is, your answers could be figured out and your account compromised.

Or, instead of answering truthfully, you can lie and hope that you can remember the answers you gave and to which questions.

A few people have virtually no social media presence, but for the rest of us, our social media footprint can tell inquiring people a huge amount about us—our likes, dislikes, our family history. Social media can betray exactly the kind of things that personal security questions tend to ask. We undermine their effectiveness if we answer honestly.

It’s always good to consider what you post to social media—intentionally or not, you’re likely sharing a huge amount of personal information with, well, everyone. Even if the accounts are not public, the companies running the services share your information with advertisers, and potentially, government agencies. So take a few minutes and think about what and how you post online, and whether you might ever wish that other people hadn’t seen it.

If you have little direct social media footprint, other people may post about your personal details. Also, quite a bit of information about you may be available in public records and databases For instance, many towns freely publish tax records showing details about home ownership. There are also services providing detailed genealogy information about family trees.

And what about your favorite food? Is it the same every day? More than half the questions United offered me were about favorites. My favorite song, movie or show may easily change depending on what I’ve watched or listened to recently. And I have several favorite foods. Which one did I say? I can’t remember.

Google published a study in 2015: Secrets, Lies, and Account Recovery: Lessons from the Use of Personal Knowledge Questions at Google. It made several important observations.

  • 37% of users provided fake answers which were often easy to guess.
  • Answers are subject to statistical attacks. For instance, many people have the same favorite food or color.
  • Potentially more secure questions are harder for users to remember than unsafe questions.
  • Users forget their answers over time.
  • SMS and email-based processes have much higher success rates than personal security questions.
  • People often give simple answers due to a false sense of security.

Google went on to replace personal security questions with two-factor authentication (either via SMS or an authenticator app) and recovery email addresses.

A 2009 study by Microsoft and Carnegie Mellon University (It’s no secret – Measuring the security and reliability of authentication via ‘secret’ questions) came to similar conclusions about the guessability and memorability of questions used to protect Hotmail, AOL and Yahoo accounts.

All this points to the fact that security questions are not merely ineffective, but dangerous for the services and users that put their trust in them.

So let’s not inflict this horrible user experience on people, and justify it by telling ourselves it’s making their accounts secure. That’s bullshit. It’s not.

So Romkey, What Do I Do?

As a user, if you come across a service forcing you to use security questions, consider an alternative. Don’t encourage poor security practices with your time and money. And don’t just switch in silence; politely contact the service to let them know why you’re going elsewhere.

If you’re a developer and can push back on the inclusion of security questions, do it. Speak truth to power. Argue that a poor user experience will lose users. Argue that security questions lead to insecure accounts, which also will lose users. Cite Google’s study. Explore and propose alternatives like multi-factor authentication or Touch ID and explain how they improve both security and user experience.

But if you’re stuck needing to use (or build) a site or app that requires personal security questions, try the following.

Use real security if possible

Users: If the service allows you to use SMS to receive a code, permits an app to authenticate you, lets you integrate a fingerprint scan instead of security questions, do it.

Developers: Make security questions optional, and offer actually secure alternatives to security questions.

Treat security questions as passwords

Users: Use strong, unique combinations of letters, numbers and the occasional punctuation. And handle them in a secure, safe manner, the way you should handle any other passwords.

Developers: Treat security question answers the same way that you treat passwords. Be sure they’re transmitted and stored encrypted and salted.

If you follow only one of these recommendations, make it this the one.

Don’t trust the service to protect your answers

When you answer security questions, expect that the organization storing your answers will do little to protect them and that a sufficiently motivated attacker will be able to discover your answers. If you believe this then giving honest answers, or using the same answers on different web sites, is a great way to make sure your account can be broken into.

Developers: Store the answers using one-way encryption then confirm identity by comparing the encrypted answers. If you normalize the answers (perhaps you convert them to lowercase or drop certain stop words like “the”), normalize the answers before encrypting and storing them, and perform the same normalization to the answer provided by the user during the confirmation process.

Use unique answers to the same questions on different services

This will protect you when a site is breached, and crackers can read your questions and answers. Use unique answers for each service, even if different sites have the same question.

Developers: Consider checking for and disallowing the same answer to multiple questions.

Lie

If the system restricts you from using strong passwords, lie about the important things. Financial sites frequently use questions like “What is your mother’s maiden name?” There is absolutely no reason they need to know your mother’s maiden name. Don’t give it to them.

And if you do lie, be sure to use answers that you can remember but that aren’t easily guessable. For instance, don’t answer “hamburger” as your favorite food.

Developers: Be sure to accept randomly mixed case letters, numbers and punctuation.The things that let users create strong passwords.

Record your answers securely

We’re intentionally using answers that are difficult or impossible to remember. So consider using a password manager like 1Password so that you don’t have to remember them.

Storing personal security question answers in 1Password

Ask the site how they protect the information they collect

How do they store it and protect it? Do they encrypt it? Do they sell it to other companies, share it with marketing partners?

Look for the website or application’s privacy policy, terms and conditions or other disclosures. If you can’t find them or if you can’t understand them, contact customer service and ask for a clear explanation.

United Privacy Policy link

Like most sites, United Airlines keeps a link to its Privacy Policy in the page footer.

 

If they can’t clearly explain how they protect your information, what kind of protection do you think you can expect? You’re best off expecting little to none and acting accordingly.

Developers: Formulate and prominently display honest and accurate privacy and data usage policies.

Security Theater

Personal security questions are an unfortunate epidemic of security theater. Like airport security, they’re all style and no substance.

When something bad happens, the service provider can shrug and say “Well, look, we tried to protect your account and information to the best of our ability!” But they didn’t. Security questions were a useful way to secure bank accounts in the 1900s. But they’re long obsolete. Only by approaching them carefully as users, and moving past them as developers, can we have better security and better usability.

 

Share this:
%d bloggers like this:
var _gaq = _gaq || []; var pluginUrl = '//www.google-analytics.com/plugins/ga/inpage_linkid.js'; _gaq.push(['_require', 'inpage_linkid', pluginUrl]); _gaq.push(['_setAccount', 'UA-239812-12']); _gaq.push(['_trackPageview']); (function() { var ga = document.createElement('script'); ga.type = 'text/javascript'; ga.async = true; ga.src = ('https:' == document.location.protocol ? 'https://' : 'http://') + 'stats.g.doubleclick.net/dc.js'; var s = document.getElementsByTagName('script')[0]; s.parentNode.insertBefore(ga, s); })();