lego heads - so many identities to choose from - alloySo many identities to choose from…

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 with use of a whispered word, banks have to resort to other methods of identification. One of these methods is “knowledge-based authentication” (KBA) questions.

They look something like this:

useless authentication question example 1 - alloy

This is just a simple example, but obviously with even a cursory Internet-stalk, you could 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, mostly 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 are 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

The recommendation, if faced with these types of questions, 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, 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?

who is writing this blog - man dog or hacker - alloyOne of these doofuses is writing this blog post right now. Can you figure out which one?

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.

face off movie

face off movieGreat movie.

Ideally, a bank should be screening using a series of questions that nobody except you and they 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 just to see if there were any trickier questions I could find. Trust me, they were all this bad.

useless authentication question example 2 - alloy

And now the answers, told by screenshots, from Facebook and Google.

Image for post authentication questions easily answered - example 3(SSN issuance is usually from the place of birth, which remains true in this case.)

Thanks a lot, Internet!

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 affected 147.9 million consumers last year. Even more low-profile data breaches from the 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 five 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 is always going to be to collect as much data as possible and look for discrepancies. This may seem like common sense, but most implementations that I’ve seen collect data in silos and don’t effectively use the whole picture to assess risk. 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 uploading 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 vendors. Go crazy!

In the fight against identity theft and fraud, we’ll have to always be innovating. It’s a cat-and-mouse game out there. Luckily, I know a company that can help. Let us know what you think!

Find out more about Alloy at, on Twitter, or follow Charles for less relevant information

Charles Hearn

Written by Charles Hearn

Co-Founder & CTO of Alloy