Following the numerous compromises of accounts to various online services (with the most news-covered being the Twitter account compromises), more and more online services are providing means for Two-Factor Authentication (2FA).
Just as a short primer, authentication is the procedure a service has in order to verify that the user claiming to want to authenticate is actually the user which holds the account. A good simple example (of one-factor authentication) is a username/password combination. I authenticate to the service by providing my username/password combination, and since I am the only on that should know this, I am authenticated as being the owner of the account.
The big problem with the above is what happens if my credentials are stolen or compromised? Well, the service can be tricked by a third person, which can provide the valid username/password combination, into thinking that the third person is me! Granted, there are cases where this is actually desirable (such as shared accounts) but in the end, the result is the same; the service has no way to identify that the person between the chair and the keyboard (or behind the touchscreen nowadays) is the account holder.
Enter 2FA. With 2FA, a user is authenticated both by something they know (username/password combination) and by something the have (called a token). This token can take many forms; the most common use case is a secure entry: an employee attempts to enter a secure facility, an is required to input in the keypad next to the door their PIN number (something they know) and swipe their proximity card (something they have). Just as a sanity check, a third party could be given the PIN and card and authenticate the same way, but this is not explored in this post (bio-metrics can come in play to mitigate this etc).
In the case of online services such as Google services, Facebook and most recently Twitter, 2FA extends the above example with the use of their username/password and a soft token; a One Time Password (OTP) generated based on the time the user attempts to authenticate.
In the case of Google and other services, they decided to go with an implementation of the OATH standard. This allows for the use of an authenticator application on your smartphone (such as Google Authenticator, Microsoft authenticator and other third party applications) to produce these OTPs. There are a number of benefits to this:
Just as a short primer, authentication is the procedure a service has in order to verify that the user claiming to want to authenticate is actually the user which holds the account. A good simple example (of one-factor authentication) is a username/password combination. I authenticate to the service by providing my username/password combination, and since I am the only on that should know this, I am authenticated as being the owner of the account.
The big problem with the above is what happens if my credentials are stolen or compromised? Well, the service can be tricked by a third person, which can provide the valid username/password combination, into thinking that the third person is me! Granted, there are cases where this is actually desirable (such as shared accounts) but in the end, the result is the same; the service has no way to identify that the person between the chair and the keyboard (or behind the touchscreen nowadays) is the account holder.
Enter 2FA. With 2FA, a user is authenticated both by something they know (username/password combination) and by something the have (called a token). This token can take many forms; the most common use case is a secure entry: an employee attempts to enter a secure facility, an is required to input in the keypad next to the door their PIN number (something they know) and swipe their proximity card (something they have). Just as a sanity check, a third party could be given the PIN and card and authenticate the same way, but this is not explored in this post (bio-metrics can come in play to mitigate this etc).
In the case of online services such as Google services, Facebook and most recently Twitter, 2FA extends the above example with the use of their username/password and a soft token; a One Time Password (OTP) generated based on the time the user attempts to authenticate.
In the case of Google and other services, they decided to go with an implementation of the OATH standard. This allows for the use of an authenticator application on your smartphone (such as Google Authenticator, Microsoft authenticator and other third party applications) to produce these OTPs. There are a number of benefits to this:
- Based on Open Standards: As such, the implementation of the 2FA procedure allows for a single client to generate OTPs for a number of services
- Ease of use: Smart phones have become quite pervasive and thus allows for ubiquitous usage in any environment. Also, since it is time based, no internet connection is needed (so no charges are associated for the token generation in case a user is travelling abroad).
- More Secure: Although this is debatable, personally I believe using your smart phone as your soft token generator is secure; I always keep my phone with me and it is locked using a pass phrase.
As a negative, this does require the user have a smart phone. Although they are pervasive, it doesn't mean every user of a service has the luxury of a smart phone.
Now, Twitter and Evernote have decided to go the route of OTP over SMS. Each time you try to authenticate to the service, a SMS is sent to the phone you registered upon enabling 2FA, and that code needs to be entered to allow for the authentication procedure to complete. This implementation has many shortcomings:
- Non Secure Protocol: SMS has no security built-in. This means that from the time the service provider sends the SMS and it gets routed through local, regional and maybe international mobile telephone service providers, the OTP is in the clear and visible by any one that can sniff the traffic. Although this is illegal to do, I have never heard of a law-abiding attacker :)
- Single device: What happens if you have multiple accounts for the service? For example, you may have more than one Twitter account. Based on the 2FA procedure they have set up, you cannot register the same device for two separate accounts. So, if you have five accounts you would need five phones!
- Charges: SMS messages incur a cost. Most countries bill not only for SMSs sent but also received. There is also the issue of international fees when traveling abroad.
- Same Channel, Two Purposes: Twitter specifically, use SMS both for their 2FA and for the facility of posting tweets using SMS messages. Although not an apparent issue, it is architecturally never a good idea to use the same channel for different purposes (please let's stop assuming the implementation is bullet proof and that one channel cannot compromise the other).
Additionally, and the one I found most irritating, I was unable to set up 2FA for my Twitter account. Not because I have two accounts or any other technical issue; it's because Twitter does not have an agreement with any of the Telco's in my country. This is what I call #FAIL.
Summing up everything, although 2FA does provide a substantial benefit, it has to be done right to provide this benefit to all users at all times. Since their is an Open Source solution, vetted and adopted by large players in the industry (Google, Microsoft, Facebook to name a few), it seems like the way to go. It is also important to note that if a smart phone application generated OTP is not a solution for a user, the aforementioned services offer the ability for the user to use SMS OTP (by choice, not because it is the only way).
No comments:
Post a Comment