Content Library
Back
Share

Why knowledge-based authentication (KBA) is not effective

Answering my own knowledge-based authentication (KBA) questions proves that they’re useless

Authentication questions are useless hero

One key feature of having a fort as a kid was the secret password to identify yourself and grant entry. Unfortunately, we don’t have this kind of relationship with our banks.

Instead of verifying your identity using a whispered word, banks have to resort to other identification methods. One of these methods is knowledge-based authentication (KBA) questions.

They look something like this:

Authentication questions useless 1

This is just a simple example, but with even a cursory internet-stalk, you can figure out the answers to these questions for pretty much anyone. Herein lies the problem. When so much personal information is available online, what does a “good” knowledge-based authentication question look like anyway?

KBA: an origin story

This practice began where many of our stories start, at the dawn of an untrustworthy internet. Websites wanted an extra verification step to prove accounts weren’t getting hijacked due to weak passwords or security breaches. Thus, they created the simple pre-shared KBA question.

When you create your account, you set the answers to something like “who was your favorite high school teacher?” These questions have since fallen out of fashion, mainly because if someone can guess your password, they can probably also guess your answer. The Open Web Application Security Project cheat sheet for authentication puts it this way:

"It bears repeating again…if passwords are considered weak authentication, then using security questions is even less robust. Furthermore, they are no substitute for true multi-factor authentication, or stronger forms of authentication such as authentication using one-time passwords or involving side-channel communications."

If faced with these types of questions, the recommendation is to use a password manager to fill in random characters as the answers.

Taking things up a notch

The previous case can only help prevent account takeover (ATO), but what about initial identity verification? In this scenario, we’re trying to match a real-world identity to a digital one, confirming that the person signing up for this online account is the person they say they are. This starts with finding a valid, real-world identity from information the customer provided, usually in a public records or credit database. Once that identity is found, the challenge commences. How can you trust, beyond a doubt, that a random person on the internet is signing up as themselves?

One of these doofuses is writing this blog post right now. Can you figure out which one?

Authentication questions useless 2

Think about it like “the evil clone” problem from a movie. Every time you sign up for an account online, the bank is trying to determine if you are you, or the evil clone.

In the movie Face/Off, Nicholas Cage tells the story of his first date with his wife to prove that he’s actually John Travolta wearing the face of Nick Cage. So that’s one option, but probably not the most effective.

Ideally, a bank should be screening using a series of questions that nobody except you and the bank know the answers to. To make it harder, there’s about half a second to do this before a customer gets bored and closes the window.

Companies frequently turn to databases and vendors to dig up bits of information that could be used for your evil clone test. This subset of super-KBA questions is often called “out-of-wallet” questions, which typically come from public records databases, credit bureaus, or, in rare cases, social media. Let’s take a look at a few of my actual out-of-wallet questions and see if they’re useful.

Preface: these out-of-wallet questions were generated for me by a popular data vendor (not calling anyone out here; the point is that they’re all bad). These were all in a single-question set. I also used two different popular vendors to generate a few sets to see if there were any trickier questions I could find. Trust me; they were all this bad.

Authentication questions useless 3

And now the answers, as told by screenshots from Google.

Authentication questions useless 4
Authentication questions useless 5

Thanks a lot, internet!

And as for the first question, SSN issuance is usually from the place of birth, which remains true in this case — so if you can find my hometown on Facebook, you can probably figure that one out too.

I’m not necessarily trying to say that KBA questions are always this bad, but when someone has a thin credit file (at least 1 in 10 Americans) or hasn’t built up a lot of previous address history, the questions are often this bad or worse.

For the small subset of people who have more complicated questions, read on…

The final nail in the coffin

Going back to the out-of-wallet sources we mentioned previously, I just wonder, how are they faring these days?

  1. Public records: hacked — the KBA database, specifically!

  2. Credit bureaus: super-hacked!

  3. Social media: oh, you know it

The Equifax breach of 2017 affected 147.9 million consumers. Even more, low-profile data breaches from other agencies predate that. This stolen data amounts to essentially all of the information used to generate out-of-wallet questions by the most-used data sources. With this information, no questions can be considered non-public. You know your technique is broken when a fraud analyst with Gartner can say this with confidence ten years ago:

"those that get the questions wrong are more often legitimate credit applicants — not the identity thieves."

This is because fraudsters have all of your credit data open on their computer. They’re looking at it while they apply for accounts in your name. You might forget the exact amount that your last car payment was, but they certainly won’t.

Moving forward

Ending on a positive note, let’s talk about solutions. The correct way to weed out identity theft will always be to collect as much data as possible, look for discrepancies, and deploy the appropriate type of step-up based on the level of risk. This may seem common sense, but most implementations I’ve seen collect data in silos and don’t effectively use the whole picture to assess risk.

For example, if a person’s utilities are being paid in Delaware, but they’re trying to sign up for a bank account from a computer in Ohio with the browser language set to Russian, add an additional verification step by having them upload a driver’s license. Or deny them. Whatever way it’s done, the logic should be dynamic. Use all of the data at your disposal. Get the data to spin a beautiful web of associations. Think about throwing in some interesting device data or behavior-based data vendors. Utilize multi-factor authentication (MFA) or authenticator apps. Go crazy!

Alloy supports a wide range of flexible step-up options through our codeless SDK, which allows clients to integrate once, then easily configure their preferred vendors without further development work. Different types of step-up verification tools effectively counter different types of fraud. For example, if the applicant is medium risk, use phone-centric identity verification, such as Prove, which utilizes customers’ phones to verify their identity. If the applicant is high risk, use a combination of phone-based and document verification along with selfie verification.

We must constantly innovate in the fight against identity theft and fraud. It’s a cat-and-mouse game out there. Luckily, I know a company that can help.

Find out more about Alloy at alloy.com, on Twitter, or tweet Charles and let him know what you think about KBA.

Alloy helps financial institutions verify customer identities and fight fraud.

Related content

Back