Every individual who has online accounts to access services or applications invariably has had to establish answers to security questions. We logon to a new bank account, social media service, or check out our favorite online paid service, and we are required to enter responses to security questions. The purpose of these questions is to periodically re-affirm our identity, or to regain access if we forget our password, by providing our answers.
Here are examples of some common security questions:
- In what city were you born?
- What is the name of your favorite pet?
- What is your mother's maiden name?
- What high school did you attend?
- What is the name of your first school?
- What was the make of your first car?
- What was your favorite food as a child?
- Where did you meet your spouse?
The problem with these security questions (and with our answers) is that they become a liability when the results are leaked online, such as through a data breach, or become public knowledge. Why? Because many (in fact, thousands) of sites potentially use identical security questions. The variation from site-to-site is low, and questions for each user frequently, and inevitably, overlap across their many accounts. This standardization of security questions creates a substantial, but unnecessary, risk.
The threat of re-used security questions is comparable to that of reusing passwords. Security pros, and end users, should know that they should never repeat a password across accounts. This is because, if one account is compromised, that password is out there in the wild attached to your credentials/identity and could be used for a future attack against any account you own that has the same credentials. When passwords are re-used across dozens of accounts, the compromise of just one account could potentially lead to the compromise of all of the other un-related accounts.
While we do usually have control over the passwords we choose, as individuals, we do not have the power to change the questions that these websites and services ask. However, we can answer these security questions in creative ways that make our accounts more secure and eliminates the threat of multiple accounts being compromised. Here is some basic guidance on how to accomplish this:
1. As much as is possible, do not select the same security questions across multiple sites. Keep your selections unique when the site allows you to pick your own questions. This will help limit the fallout and compromise of other accounts if the security question/answer is ever leaked. This is especially important for public figures whose history may be a part of public record or biographies posted on websites. For example, we all know the city our favorite musician or actor was born in, right?
2. Do not answer security questions in plain English (or your native language). That is what is expected, but it’s a security misstep. Treat your answers like passwords and introduce complexity in your response and its characters. For example, let’s say I was born in Little Rock, Arkansas. The security question for, “what city where you born in” would require the response, “Little Rock”. Now, add some password complexity. The new entry could therefore be, “L!ttl3 r0ck”. This answer is more difficult to guess or crack through automated tools and provides a simple layer of obfuscation to protect your security question responses. And, if anyone ever asks, you can honestly state that of course your mother’s maiden name does have numbers and symbols in it. Doesn’t yours?
3. In many instances, the best course of action is to provide fictitious information to these questions to keep them unique. You could use a personal password manager to populate the answer fields with password-like responses. Then, store each question and response in your password manager. For example, for an ecommerce site, you could create the entry “ecommercesite.com/question_birthcity” as the account and then enter a random, recommended password as the security response. This provides the secure storage you need in case of a password problem, while keeping your answers to same security question completely random and unique across sites and applications.
Security questions were designed with the intent of strengthening identity validation for access to applications and websites, particularly in the case of a password issue or other fault. However, just as with password reuse, reusing security question and answer pairs across multiple sites has enabled threat actors to compromise many accounts associated with an identity. Typically, this requires a hacker to compromise a secondary application as well, like email or SMS texting, in order to pair a password reset with the knowledge of these security questions. Unfortunately, some websites and applications do not even go that far and knowledge of a security question answer is sufficient to compromise the account.
For IT and security professionals interested in a more rigorous and thorough examination of all the ways identities (corporate and personal) are at risk or under attack, and the best strategies for protecting them, check out: Identity Attack Vectors: Implementing an Effective Identity and Access Management Solution, a new book co-authored by Darran Rolls, CTO at SailPoint and myself. You can also watch our joint webinar on-demand: Deconstructing Identity as a Cyberattack Vector.
Morey J. Haber, Chief Technology Officer and Chief Information Security Officer at BeyondTrust
Morey J. Haber is Chief Technology Officer and Chief Information Security Officer at BeyondTrust. He has more than 25 years of IT industry experience and has authored four Apress books: Privileged Attack Vectors (2 Editions), Asset Attack Vectors, and Identity Attack Vectors. In 2018, Bomgar acquired BeyondTrust and retained the BeyondTrust name. He originally joined BeyondTrust in 2012 as a part of the eEye Digital Security acquisition. Morey currently oversees BeyondTrust strategy for privileged access management and remote access solutions. In 2004, he joined eEye as Director of Security Engineering and was responsible for strategic business discussions and vulnerability management architectures in Fortune 500 clients. Prior to eEye, he was Development Manager for Computer Associates, Inc. (CA), responsible for new product beta cycles and named customer accounts. He began his career as Reliability and Maintainability Engineer for a government contractor building flight and training simulators. He earned a Bachelor of Science degree in Electrical Engineering from the State University of New York at Stony Brook.