I’ve taken a lot of questions lately on the topic of KBA.  KBA (Knowledge Based Authentication) is a general term that covers several types of scenarios where users are asked a set of questions to verify their identity for situations where there isn’t another credential available to authenticate the user.  There are various cases where this is used:

1. A user you don’t know.
2. A user you do know.

The user you don’t know

Typically this is when a user shows up to register for service and likely will end up with an authentication credential at the end of the process, which they will use going forward to authenticate themselves.  KBA is generally used in this case to prove or establish the identity of the user and again, generally for services where the user’s true identity really matters because of regulations or other legal “know your customer” types of strictures.

The user you do know

This is for the situation where a registered user who does have a valid credential / identity with you, but for some reason isn’t able to utilize that authentication mechanic to login.  Typical use cases for this are when the user is for one of the following reasons unable to login with their proper credential:

• User has forgotten their password.
• User does not have access to their second (or third) factor in a strong authentication situation.  Anyone who has needed to login when they didn’t have their hardware (OTP token, hardware smartcard) or software token (cookie, software token, software smartcard) has at one time or another encountered this scenario.

Types of KBA

There are three methods of accomplishing KBA.

1. Questions the user knows, but you do not.  Generally speaking these Q&A pairs are obtained via services that utilize public or semi-public data sources to ask questions about a user.  These questions can take a wide range of form and are often referred to as “out of wallet” questions as they questions that couldn’t be answered by a thief who as stolen a users wallet.
   • Provide the address where the user lived during a range of dates.
   • Provide the amount of a recurring payment (mortgage, car, etc.)
   • Provide the proper relationship (spouse, father, sibling, etc.) the user has with a name person.
   • Other questions that can be directly or indirectly built from public and semi-public information.
2. Questions both the user and you know because of a prior existing relationship outside the online channel.  These Q&A pairs are derived from information you have about the user from a relationship you have with them outside the online relationship.  This can take any number of forms, but the typical scenario most are familiar with are:
   • Amount of last transaction
   • Account number used to make transactions
   • Other information you have that the valid user should know or be able to readily obtain.
3. Questions you and the user both know because the question / answer pairs were setup as part of the online relationship.  These Q&A answer pairs are either previously arranged (consequently often referred to as “static KBA”), usually at registration or something setup post-registration as part of the user’s profile specifically for helping the user accomplish authenticating themselves when there is an issue using their normal authentication credential.

Clearly, KBA Type #1 is great to use for those users you don’t know and want to identify as being exactly the person they claim to be.  If you are setting up an online relationship from scratch and don’t have any prior basis upon which to “know your customer” and need to know that John Smith is the John Smith at 123 Main St., Somewhere, Ohio, U.S.A. and want to do this all online, then is a good way to go about it.  There are a fair number of services that provide exactly this function, generally used at registration or initial provisioning of login credentials.  One of the main considerations to bear in mind when shopping for these services is how well they structure the questions such that the legitimate user can answer them and an attacker can’t obtain the answers from publicly available sources or guess the answers.  This can be harder than it sounds as balancing the increased security of this type of KBA vs. static KBA and keeping the questions from frustrating and confusing end users, is a tricky proposition.

This isn’t to say that KBA Type #1 can’t be used for other use cases such as self-service forgotten password resets or “step-up” authentication or other secondary authentication use cases.  It can be used for those as well, but may be a higher cost type of transaction than using either KBA Type #2 or #3. 

KBA Type #2 is a lower cost option when having an existing cusstomer you know sign-up online for services.  This can also be used for other use cases as well, though asking questions that aren’t too readily guessable or aren’t reused too often can be difficult depending on the amount of variable, private or semi-private information you have on your customers.  For instance, my mobile phone bill doesn’t vary that much month to month and the people I call are probably pretty easy to guess for anyone willing to spend a bit of time researching me, so those types of questions wouldn’t serve very well.

Which brings us to KBA Type #3.  All of us that participate in much of anything online are familiar with this one.  You set up an account and at registration are asked to setup at least one or more questions to be asked for any number of reasons including:

• Self-service “forgot your password?” scenarios
• Various renditions of, “We don’t recognize you having used this computer”, “We want to verify you’re identity”, “Reset your <proprietarily named security “token”>”.  This occurs when you are logging in from a device the site doesn’t recognize or you or your anti-virus / anti-malware software deleted your cookies such that the authenticating site wants to make sure you aren’t an imposter.
• Step-up authentication.   You attempt some transaction or behavior deemed “risky” by the site, so again, they want to ensure you aren’t an imposter.

You usually get to pick from a list of drop down questions and in some cases even can write your own questions.  This is popular since it is inexpensive as there is no service provider to pay and reduces the number of help desk calls for high frequency events, such as “I forgot my password”. 

There are a couple drawbacks.

• You don’t want to have users setup questions that are easily guessed or readily discovered (mother’s maiden name) or for which the set of answers is small (many people have the favorite color blue).
• Users don’t remember answers to less obvious questions, fail the step and call the help desk anyway.
• The simpler you try to make it by keeping the number of questions low and even with complicated questions, the entire scenario of static KBA is prone to phishing and guessing attacks.  After all, KBA Type #3 (aka “static KBA) is just another single factor, something you know, shared secret, i.e. a ”password”.

There have been an increasing number of news items about the compromise of politicians, celebrities and even services being “owned” via KBA compromise.  Which brings me back to the beginning of this article and why I am hearing so many questions and such confusion over the issue of KBA. 

Folks want to know:

• What are the best questions to ask?
• How many questions should I ask?
• Do I provide questions or let the user pick their own?
• Should I use static / Type #3 KBA at all or go with Type #1 KBA for all use cases?

These are tough questions to answer in the face of KBA’s growing list of failures.  Mark Diodati over at Burton Group has written a ton on the issues of KBA and in a May 29th article states what my personal opinion is with regard to KBA:  “Can We Finally Commit to the End of Knowledge-Based Authentication?“.

Yahoo and Google, who in the last year have both had high-profile users in the news with compromised accounts because of hacked KBA, have apparently decided that KBA needs help.  They are both offering the ability for end-users to use their mobile phones instead of KBA for resetting passwords and I hope for any other secondary authentication opportunities that may arise in the use of their services.

Yahoo’s wording is:  “Having your mobile number will help future password reset attempts. ”  I thought for sure I had a security question setup on Yahoo, but now can’t find it anywhere.  My test drive of their forgotten password procedure tonight shows that my phone is the default or I can pick a non-Yahoo email to use for the ID verification step.  No security question offered.  I don’t know how much they are promoting this yet, but hopefully a lot and soon.

Google’s Account setting page lists email, SMS to your phone and a security as options for password recovery.  When I ran my test there tonight I was advised that an email and a SMS phone message had been sent to assist me in recovering my password and a link for each was provided so I could pick which I wanted to use.  While Google does still have a security question and answer, that can’t be used until my account has been idle for 24 hours.  Interesting compromise.

Which brings me to the title of this article “Trend in KBA?”.  Google and Yahoo are moving away from KBA, static, Type 3 KBA to be exact, shouldn’t those for whom reputation is even more important consider doing so?  I know this is a battle that till now has been dominated by the business and bean counter side of the organization while the security folks get ignored as usual as being unrealistic and alarmist.  Time to listen to the security folks and dump KBA.