With the rise in need for cyber security in a world where our long-reliable password prompt is finally showing its age, the terms of two-factor, and multi-factor authentication as the next-generation alternatives are being tossed around quite a lot. Unsurprisingly, following the popularization of the concept has been a fair amount of misuse and misunderstanding of the term; which is largely due to a lack of standardization for mechanisms of authentication. Here we will take a look at exactly what it means for an authentication to be two-factor, what it doesn’t mean, and how many solutions that claim to be two-factor are indeed not alike, especially when it comes to their purported level of security.
What exactly does it mean for an authentication to require two or more factors to grant access? We’re all very familiar with single-factor authentication, in the form of that looming simple password prompt that can be found protecting just about any service or website login we use today. A progressive few have taken the step towards enabling two factors for their logins: Google, Microsoft, PayPal, and Amazon Web Services, who have all provided the option of enabling a requirement for a second factor, beyond that first factor of a simple password, for those equally progressive users desiring greater security protecting their accounts. How these additional factors take form varies per implementation, and so the general definition of having multiple-factor authentication is simply having more than the usual one-factor password requirement involved in the authentication. What sorts of methods these factors should use to prove identity is easily disputed; however fortunately there are at least some ground-rules when it comes to what forms are valid factors of authentication and which are not.
What are valid factors?
In September of 2001, the Federal Financial Institutions Examination Council (FFIEC) had published a set of guidelines on the topic of multi-factor authentication after having witnessed a variety of vendors incorrectly citing their logins to be two, or multi-factor enabled titled “Authentication in an Internet Banking Environment” – with the emphasis on Banking institutions due to the unprecedented need for security in those environments. The purpose of the paper was to clear up confusion regarding these terms and lay a foundation of criteria against which authentication mechanisms can be classified as involving multiple factors or not. Criteria splits valid authentication factor methodologies into three fundamental categories:
– Something the user knows
This is the category that the simple ‘password’ exists in. It is comprised of information the user, and the user alone, has knowledge of such as usernames and passwords, PINs, or patterns to be input. These are the most common form of single-factor authentication methods, and are often the first factor in multi-factor solutions.
– Something the user has
Specified here are factors that the user and only the user are in possession of. A basic example of this is your ATM card, which is required to be in your possession in order to complete transactions at ATM machines. Notably, the PIN/Card combination required for these transactions makes ATM authentication two-factor. This category has a very wide variety of possibilities with varying pros and cons that I will touch upon later; from connected/disconnected physical tokens, smartcards, software tokens and mobile phones.
– Something the user is
These factors involve serving a unique characteristic of yours in order to prove identity. A common example of this is fingerprint or other biometric characteristic scanning. A device scans the characteristic, extracts critical information from it, and stores the result in string or mathematical form. Biometric authentication is generally less developed than the other two categories due to the expenses involved in having sensors and other equipment to do the reading. Eye retinas are another common feature scanned for biometric authentication, though in essence, any trait that is both consistent and unique to an individual is viable for this option.
What are not valid factors?
In August of 2006, the FFIEC had then published a supplement FAQ to their original, which clarified their position even more firmly by stating that “By definition true multifactor authentication requires the use of solutions from two or more of the three categories of factors. Using multiple solutions from the same category …would not constitute multifactor authentication”. This effectively constrains true multi-factor authentication to involve at least one factor from each category, denying those solutions that involve say, two factors based on ‘something the user knows’, from being considered true multifactor security. The most noteworthy example of this is approaches that involve a password for the first factor, followed by a set of challenge/answer questions for the second. Both requirements involve something the user knows, and nothing they have or are, failing to constitute as multi-factor. In the same document, it is also stated that login IDs, usernames, or other similar credentials are not considered true factors, due to the fact that they are not secret.
What are the best factors?
In June of 2011 the FFIEC published yet another supplement which addresses the effectiveness of controls found in layered security programs, multifactor authentication being one such layer. It reiterates that layered security approaches “substantially strengthen the overall security of Internet-based services…” and then provides some detail discerning the effectiveness of certain authentication techniques. Specifically it refers to additional factors of authentication that fall under the second category of ‘something the user has’, and even more specifically, software that implements device identification techniques for that factor – whereupon the device itself becomes a factor of authentication.
As mentioned earlier, methods of authentication in this category have a wide range of forms, from physical devices, cards or tokens one physically carries with them, to software based tokens, such as the ‘thumbprint’ device identification techniques generate that represents the device you are using. Whereas these types of tokens are more criticized for their security, based on the ease of impersonating or duplicating a software token as compared to a physical, out-of-band device or token, the supplement document elaborates on effective ways to remove these risks.
It first draws a distinction between what they refer to as “Simple” or “Complex” device identification techniques. A simple technique involves a cookie on a user’s machine that is generated by including characteristics of the machine such as geo-location or IP address, which serves as the soft token in the authentication. A complex approach first uses more advanced ‘time based’ or ‘one-time’ cookies, to disallow use of the soft token outside of a small time frame in case it is somehow compromised. In addition, the ‘thumbprint’ of complex device identification looks at a number of characteristics to form it, including PC configuration, time of day, IP address, geo-location, among others; the more characteristics that are taken into account, the greater the difficulty in impersonating the token.
An additional thing to consider with multi-factor approaches that involve out-of-band solutions the user has, such as email links, Mobile phone one-time-passwords (OTP), or other devices separate the authenticating software is their being unsecure in their own communications. In a two-factor authentication involving data being sent to a device, such as a mobile phone receiving an SMS text message with an OTP, if the devices own security is poor, that secret can be intercepted and reused. It is important to note that these multi-factor approaches require all devices involved to apply the proper data obscuring techniques in addition to the web based login itself.
Finally, it must be said that, similar to the above point, any factor of authentication is only as good as its inherent security. Passwords must be complex enough to warrant off brute force attacks, as well as OTP values or strings or mathematical constructs that represent the thumbprint of device identification or contextual data must have an appropriate level of entropy so that they are non-reproducible or easily decipherable. Storage of these values must also be obscured. In the case of physical tokens, the token must be able to be disabled in the case of it being lost and potentially used by an illegitimate party. Possibly most importantly, any approach and its weaknesses are nicely and effectively complemented and strengthened with additional factors of authentication, and additional layers within that factor; the best interest at this point, is simply usability.