Website secure login: Alternatives to out-of-wallet questions

Learn about alternatives to static knowledge-based authentication and out-of-wallet questions for secure website logins in this tip.

Knowledge-based authentication (KBA) is a challenge-response method of verifying a person's identity. The challenge...

is a question based on something only the individual being authenticated should know, or so the theory goes. KBA is a popular method of authentication for online services and is commonly used for self-service password recovery when users forget their passwords.

Anyone managing a site that collects usernames and passwords should consider whether the use of KBA is really fit for purpose.

Static KBA is based on a pre-agreed set of shared secrets. These can either be factual, such as the city where the user was born, or preference-based, such as his or her favourite colour. This information is collected when the user registers for an account. Ideally, the answers are easy to remember, can't be easily guessed and don't change over time. The big problem, though, is that 99% of the answers could be found in a dictionary and are more guessable than an alphanumeric password. Also, a lot of the answers to users' shared secrets are common knowledge or easily obtained. These attributes fly in the face of everything that's been written about the qualities of a strong password.

Sarah Palin's Yahoo account password was reset by a hacker answering her shared secret question, "Where did you meet your spouse?" along with her date of birth and zip code, all of which were found online. A similar situation happened with Paris Hilton's T-Mobile account. Hackers answered her secret question, "What is your favourite pet's name?" by looking it up on the Web. The assumption that you can confirm somebody's identity if he or she knows the correct answer to a secret question is clearly flawed.

An additional drawback to preference-based questions is the correct answer may be different at a later date as when the person registered. Users may not remember who their favourite rock band was two years ago. Changing preferences means answers are often no easier to remember than an eight character-long password, defeating the whole point of KBA.

For some reason, few implementations of static KBA give users the option to change their questions or answers. Again, this is poor practice when compared to the advice given regarding regularly changing passwords. Giving users the option of creating their own questions doesn't really solve any of these problems, other than in situations where the company operates internationally, and some standard questions may be either irrelevant or offensive in other countries.

So why is static KBA so popular? One reason is it's easy to implement and use, but the real answer is that it's cheap. Manual password resets, where users have to contact a help desk to get their password changed, is expensive. Using KBA as a secondary means of authentication to allow users to reset their own passwords saves a lot of money. Also, there is no need to spend money on hardware devices such as one-time password generators or make expensive changes to network infrastructures; shared secrets use much the same code as username and password forms.

To combat the shortcomings of static KBA, some organisations are turning to dynamic KBA, which generates questions “on the fly” based on information collated from public records or records such as credit reports. Because these questions don't require an existing relationship with the user, they can give a higher identity assurance during account creation. For example, by giving my date of birth and postcode, the system scans public records to generate a question like: “What make of car did you own in 1998?”

Known as out-of-wallet questions, because the user is very unlikely to have the answer to hand, they are more secure than static KBA, but don't really solve the weaknesses of KBA. A determined hacker may well be able to find or deduce the answers from online research. There's a risk, too, that legislation may limit the life of this type of KBA, as several governments in Europe have declared it illegal to use their public records for commercial use. Also, for the user there is the perception that a company may be looking at information it doesn't really need to know.

An alternative approach to KBA is to use secret sounds or pictures rather than personal information. The user is presented with a vareity of images from which he or she makes a selection. When the user is next challenged, he or she must duplicate the selection in the same order. This is not necessarily something a user is going to find easy to remember, particularly if he or she doesn't access the service on a regular basis.

Most users probably value convenience over security, but it doesn't mean system administrators should. Answers to secret questions are basically easily guessed words, and so are weaker than passwords; in many ways they weaken rather than strengthen the quality of a website secure login. They are probably OK to be used in low-risk situations, such as enabling a user to retrieve a forgotten password so he or she can post a comment on a blog site, but for any high-value transaction sites or services, they really don't make the grade.

Although stronger authentication methods are more costly and usually require new technology, customer support and education, costs of implementing these methods are coming down, and the fines for failing to protect users' data are going up. One-time password generators, out-of-band authentication, such as telephone and text messages, and standards such as OpenID all provide far more secure methods of authentication than KBA for sites handling personal or financial data.

Even if your particular site isn't high risk, a hacker obtaining your users' passwords could go on to attack more valuable sites, as many people reuse the same password across the Web. Anyone managing a site that collects usernames and passwords should consider whether the use of KBA is really fit for purpose.

This was last published in July 2011

Dig Deeper on Web application and API security best practices

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.