Following Twitter's announcement, the media and supposed security industry pros once again continued to perpetuate confusion over what constitutes "Authentication" versus what constitutes "Verification." Bloggers over at CNET provide two fine examples of this confusion just yesterday in response to the Twitter news. First, at 2:44 PM PDT on May 23 (time stamped as of 5:00 AM PDT on May 24), Jason Cipriani posted, How to use Google Voice with two-step authentication. Shortly thereafter, at 5:29 PST (time stamped as of 5:00 AM PDT on May 24), Seth Rosenblatt posted, Two-factor authentication: What you need to know (FAQ). Jim Fenton, the Chief Security Officer for OneID, a company that doesn't even address either 2FA or 2SV, has the industry credentials to seem reputable, but fails to effectively convey the difference between the two methods in his recent posting, Two-factor authentication is a false sense of security.
Look around a little deeper at the companies that are implementing similar solutions, and the vocabulary remains a bit inconsistent.
- Twitter added an "Account Security" option to its account settings to "Require a verification code when I sign in."
- Google refers to its process as 2-Step Verification.
- Microsoft similarly refers to its process as Two-Step Verification.
- Facebook is the only company that refers to its Login Approvals process as Two Factor Authentication.
This vocabulary confusion over authentication methods is the same to security as the confusion over virtualization methods is to cloud implementations. There is a real difference between 2FA (or the more generalized multi-factor authentication) and 2SV, both in implementation and in the security that the methods provide. Confusing them puts businesses and individuals at greater risk than if they didn't use them at all. The following is a brief tutorial on different authentication methods and how 2SV and 2FA differ from a security perspective.
Authentication can have any of three characteristic, or factors. They include:
- Something you know (e.g. password);
- Something you have (e.g. card); and/or
- Something you are (e.g. fingerprint).
When it comes to online authentication, we are most familiar with Single-Factor Authentication. To log in to our favorite web sites, we generally provide something that tells the site who we are (a username), and then something we know to prove who we are (a password). Credit cards represent another good example of a single-factor authentication, in that they represent something that we have that alone can grant access to funds associated with us.
Multi-Factor Authentication (MFA), from which 2FA is derived, means that the user provides things from either two or three of the factors to prove who they are. The best example in common usage is when we use a bank card at the ATM or a retail debit station. To prove who we are so that we can disburse funds from our bank account, we must provide a card (something we have) and a PIN number (something we know). In the online world, I see 2FA being most used to access some financial sites, (e.g. E*Trade's Security ID), and in corporate settings to access internal resources using a Virtual Private Network (VPN) connection combined with a token like RSA's SecurID.
2SV is something altogether different. The common technique employed by the sites referenced above is for the user to first provide a single factor (e.g. a password) to prove identity. Then, the site will send a PIN number to a registered mobile phone that the user must enter in a "second step" to verify that they are actually who they say they are. Stronger, sure, but not 2FA. In this case, the second step represents a "shared secret," information that both the user and the web site have for the purpose of the transaction. They share a common factor, something the user knows, rather than span multiple factors.
So, what's wrong with that? Security, that's what. It's like saying that aluminum is the same as steel. You might use either to frame a wall in an office suite, but you won't use aluminum for structural support of a building. It just won't hold it up.
First, if we equate the mobile phone used in 2SV as "something you have" and therefore as a second factor, then it has the same weakness as the same factor in 2FA of being subject to theft. But, the 2SV attack surface is much broader. For example, a semi-knowledgeable hacker can easily clone a cell phone with very limited information or can even just intercept text messages when in proximity to the phone (search only for SMS Interceptors to know more). Also, Mat Honan over at Wired wrote a great and tragic series of articles last year demonstrating how social engineers used publicly available information about him to gain enough access to his accounts to change critical information that wiped out his digital life, in some ways, completely. Whereas the attacker would generally need direct access to the device in a 2FA scenario, the device can be easily circumvented in the PIN-to-Phone scenario leveraged by 2SV.
Second, most 2SV implementations generally only verify the computer or mobile system itself as one that the user is connecting to the site with, and maintains that verification persistently. In that case, theft, use of that system, or perhaps even cloning of that system's network characteristics would negate the need for the attacker to capture the PIN as the system is already verified with the site. 2FA implementations, in contrast, are always on and are required for each authenticated session.
Third, 2SV has no mutual verification component. In a token-based 2FA solution like RSA SecurID, the device and the server have a shared secret that help them stay synchronized over the lifetime of the device. When implemented correctly, the token issued by the site owner will only ever work for that owner and will only ever be associated with that user. An attacker would need to take total control over the actual servers that host the web site to either pretend to be that site owner or to somehow change the token associated with the user account. By comparison, the PIN-to-Phone 2SV method is still very susceptible to a site spoofing attack where a phishing email can lure the user to a bogus web site that looks very much like the one the user intends to use to gain "man-in-the-middle" access to the user's account. You have to ask yourself, "how much do I really trust the site that I'm logging in to?"
Educating people on security is hard enough without confusing vocabulary. 2SV is a stronger authentication method than simply requesting a username and password pair, but the additional strength requires very little additional effort for an attacker to defeat. It also continues to put the onus on the user to take responsibility for not just maintaining control over authentication factors, but also on verifying the site with whom he or she is communicating with. 2FA provides a much higher level of trust by helping protect users from themselves while also providing more balance to who is responsible for maintaining the integrity of the authentication process.
All of that said, modern strong authentication methods, including both 2SV and 2FA, are still subject to the most common session hijack attacks. I'll discuss that more some other time.
UPDATE June 6, 2013
I credit Seth Rosenblatt, one of the CNET writers I referenced in the beginning of this posting for following up on my complaint. His comment is below and he states that 2SV and 2FA are commonly used interchangeably. To that point, I agree. My argument, though, aims to answer the question of whether the terms "should" be used interchangeably.
At the heart of my concern is the IT industry's tendency to create buzzwords out of terms that already have a meaning and then for those terms to slowly devolve into nothing but marketing. This seems to usually occur out of corporate marketing departments that try to pivot existing company services to meet emerging needs. Cloud computing is a current example of this marketing pivot as traditional hosting providers attempt to relabel their services as part of the "cloud" by allowing organizations to rent rigid virtual machines without the dynamic provisioning usually associated with cloud.
In this case, however, I generally don't see the organizations as the ones making the claim that what they do qualifies as 2FA. In addition to the examples I gave before, Dropbox also refers to their similar authentication offering as two-step verification, as does LinkedIn for their new service. Other than Facebook's incorrect use of the 2FA terminology, it seems that the interchangeable use resides mainly within the media domain, not the corporate domain.
Why is this important? Compliance and regulation. Wikipedia's page for Multi-Factor Authentication includes a reference from a document from the Federal Financial Institutions Examination Council (FFIEC), a financial industry regulator in the U.S., titled "Frequently Asked Questions on FFIEC Guidance on Authentication in an Internet Banking Environment." While I don't have the wherewithal to independently verify the source, I'll take Wikipedia at it's crowd-sourced word (despite it's inclusion of 2SV apps on the MFA page). The reference states: "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." I argue that the 2SV mechanisms that leverage SMS are simply allowing a second "shared-secret" to be added to the chain that already includes something the user knows (a password). That it purportedly arrives over a mobile phone presumes that SMS is constrained to the mobile phone, which it is not.
The National Institute of Standards and Technology (NIST), the policy source for all U.S. Government agencies, also discusses various assurance levels in relation to authentication. In its Special Publication 800-63: Electronic Authentication Guideline Revision 1, it provides definitions for four levels of increasing authentication assurance. NIST characterizes MFA at Level 3 (the primary MFA-related assurance level) as being "proof of possession of a physical or software token in combination with some memorized secret knowledge." Because SMS can be so distributed (as in a Google Voice context) and can be intercepted, having sole possession of a shared-secret token distributed over SMS cannot be reasonably proved. Therefore, to equate 2FA and 2SV may be dangerous to less-informed managers who find that they implemented insufficient security to meet the standards set by their regulators.
That's not to say that 2FA cannot be found within the 2SV space. Just as I argue that the common 2SV implementation is not the same as 2FA, primarily because it simply adds a second instance of the same factor represented by a password, I would argue that Google actually does provide 2FA in it's Google Authenticator app. Rather than share a one-time use secret with the user, the Google Authenticator app gives the user the ability to generate the code that Google then verifies at the time of authentication. The app is tied directly to the mobile device, meeting the possession criteria that I state above, and therefore works more akin to the RSA SecurID 2FA model than the SMS 2SV model.
As a final note, I would be remiss if I didn't call out Nicole Cozma over at CNET for her reference to LinkedIn's new system as 2SV. I don't know if my posting caused a change in how related terminology is being used, but I wanted to show some appreciation for what I consider correct usage.
UPDATE June 6, 2013
I credit Seth Rosenblatt, one of the CNET writers I referenced in the beginning of this posting for following up on my complaint. His comment is below and he states that 2SV and 2FA are commonly used interchangeably. To that point, I agree. My argument, though, aims to answer the question of whether the terms "should" be used interchangeably.
At the heart of my concern is the IT industry's tendency to create buzzwords out of terms that already have a meaning and then for those terms to slowly devolve into nothing but marketing. This seems to usually occur out of corporate marketing departments that try to pivot existing company services to meet emerging needs. Cloud computing is a current example of this marketing pivot as traditional hosting providers attempt to relabel their services as part of the "cloud" by allowing organizations to rent rigid virtual machines without the dynamic provisioning usually associated with cloud.
In this case, however, I generally don't see the organizations as the ones making the claim that what they do qualifies as 2FA. In addition to the examples I gave before, Dropbox also refers to their similar authentication offering as two-step verification, as does LinkedIn for their new service. Other than Facebook's incorrect use of the 2FA terminology, it seems that the interchangeable use resides mainly within the media domain, not the corporate domain.
Why is this important? Compliance and regulation. Wikipedia's page for Multi-Factor Authentication includes a reference from a document from the Federal Financial Institutions Examination Council (FFIEC), a financial industry regulator in the U.S., titled "Frequently Asked Questions on FFIEC Guidance on Authentication in an Internet Banking Environment." While I don't have the wherewithal to independently verify the source, I'll take Wikipedia at it's crowd-sourced word (despite it's inclusion of 2SV apps on the MFA page). The reference states: "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." I argue that the 2SV mechanisms that leverage SMS are simply allowing a second "shared-secret" to be added to the chain that already includes something the user knows (a password). That it purportedly arrives over a mobile phone presumes that SMS is constrained to the mobile phone, which it is not.
The National Institute of Standards and Technology (NIST), the policy source for all U.S. Government agencies, also discusses various assurance levels in relation to authentication. In its Special Publication 800-63: Electronic Authentication Guideline Revision 1, it provides definitions for four levels of increasing authentication assurance. NIST characterizes MFA at Level 3 (the primary MFA-related assurance level) as being "proof of possession of a physical or software token in combination with some memorized secret knowledge." Because SMS can be so distributed (as in a Google Voice context) and can be intercepted, having sole possession of a shared-secret token distributed over SMS cannot be reasonably proved. Therefore, to equate 2FA and 2SV may be dangerous to less-informed managers who find that they implemented insufficient security to meet the standards set by their regulators.
That's not to say that 2FA cannot be found within the 2SV space. Just as I argue that the common 2SV implementation is not the same as 2FA, primarily because it simply adds a second instance of the same factor represented by a password, I would argue that Google actually does provide 2FA in it's Google Authenticator app. Rather than share a one-time use secret with the user, the Google Authenticator app gives the user the ability to generate the code that Google then verifies at the time of authentication. The app is tied directly to the mobile device, meeting the possession criteria that I state above, and therefore works more akin to the RSA SecurID 2FA model than the SMS 2SV model.
As a final note, I would be remiss if I didn't call out Nicole Cozma over at CNET for her reference to LinkedIn's new system as 2SV. I don't know if my posting caused a change in how related terminology is being used, but I wanted to show some appreciation for what I consider correct usage.
No comments:
Post a Comment