On Multiple Single Factor Authentication

Two factor authentication is fast becoming an industry standard for high value applications. Unfortunately a lot of misunderstanding surrounds two factor authentication, and thus, the implementation is often less than ideal. Two factor authentication, strictly speaking, requires a user to provide information from two separate sources in order to authenticate. These sources can be diverse, but the most common source by far is something the user knows (such as a password). The second factor can be provided by a key fob, a smart card, biometrics, or any number of other sources.

The largest misunderstanding in implementation of two factor authentication is the use of a second piece of information that the user knows as the second factor. Strictly speaking this is not two factor authentication, but rather multiple single factor authentication. Because the authentication is strictly based on things the user knows it is not necessarily any more secure than simply using a username and password (which, in and of itself is multiple single factor authentication).

To make matters worse, many multiple single factor authentication utilizes so called "security questions" as a "second" factor. This scheme, made popular by many financial websites, creates several problems.

The biggest problem with "security questions" is that they seek a static answer. That is to say that the answer to the question never changes. In many respects this weakness is shared with biometric authentication. The problem with static responses is they cannot be changed. This makes them vulnerable to brute forcing attacks. If the response is ever compromised it can never be used again. Furthermore, static responses to security questions are often deducible by outside parties (for instance, it is possible by examining birth and marriage records, to determine the maiden name of someone's mother, the place they were born, etc.).

Another serious problem with "security questions" is that they are used across multiple systems as an identifier and thus suffer from the same problem as social security numbers. Many different systems utilize "security questions" and because the answers are static they do not change to be unique on a per system basis. Thus users' answers to security questions are shared, and compromise of one system jeopardizes the security of all other systems utilizing the same "security question" schema.

One response to these challenges has been to allow users to craft their own questions. While this seems reasonable, it presents a problem that has long been known to password security experts. People tend to choose security data that is familiar to them. They re-use passwords across systems because this strategy makes remembering easier. Allowing users to choose their own security question gives them the option of utilizing weak questions (such as "what color is your hair" or "where do you work"). This system allows users to choose questions that are in fact easier to compromise than even mother's maiden name.

Another problem arises when a system collects answers to security questions. This scenario means that the system administrators suddenly become privy to a wide breadth of security sensitive information that could be used to access other systems. In a sense, users give sysadmins access not only to the credentials the user utilizes to access their systems, but also the credentials to other systems. Even if this data is hashed to protect it from plain view, brute force and other means can be used to recover the data.

Finally, there is no enforceable mechanism to enforce complexity to answers to security questions. In many cases the answers will be short and comprised only of alphabetic data. This means that the so called second factor is in many cases even easier to crack than a regular password. The "second factor" becomes little more than a speed bump to brute force attacks.

While the intention of this type of multiple single factor authentication is laudable it is astounding how seriously flawed the implementation is given the wide array of research on passwords that is available. Assuming a system intends to utilize multiple single factor authentication then the second factor should certainly be another password. This simple solution, forcing a user to have two passwords, is easily implemented utilizing many of the resources already used for existing systems. A second factor can be enforceable strong, unique to the system and allows for expiry. The fact that a second password meets all of these criteria suggests it strongly when compared to common methods that fail to meet at least one, if not all, of these litmus tests.