Fundamental OTP Disadvantages & Problems in Two-Factor Authentication
January 14, 2014 •
Use of one time passwords (OTPs) as a second step to logging in seems to be getting more popular recently. There are two main approaches to OTPs, the first being delivery of the OTP over a channel like SMS, and the other being a code that changes every time you use one to log in or on a predefined time schedule, based on a predefined algorithm. To use the first type, one must have a device with network connectivity and a phone number to recieve SMS. With devices like RSA SecurID tokens or Google Authenticator, a person can generate the second type of OTP.
However, there is a reason this is referred to as “two-step” authentication instead of “two-factor”. Put quite simply, both types of OTP suffer from several drawbacks, and SMS OTP doesn’t even offer a second factor.
SMS OTP is not a Second Factor
When you log into a site using SMS OTP, you get an SMS message containing an OTP sent to a phone number you configured earlier. The idea is that an out-of-band channel is unlikely to be monitored by the same attacker that is trying to authenticate illegitimately.
The first issue here is one of trust. The assumption is that an attacker can’t intercept the OTP from the SMS message, so you’ve got to trust the mobile network operators to run a secure network. In the case of a roaming user, multiple networks may have to be trusted. Even if you trust the operators of the mobile networks, you’ve still got to contend with mobile malware that intercepts the SMS messages, and the fact that the encryption used on cellular networks is known to be weak.
Even assuming you’re satisifed with the security of the mobile network and the end user devices, SMS OTP still does not provide a second factor. An SMS message is not something you have, it’s just a message sent to you. It can be copied and used by others, so it doesn’t count as a second factor. Your phone number isn’t something you have either, it’s just an address, and you can transfer a phone number to a new device fairly easily anyway. The only other thing involved is the phone itself, but that’s only used for receiving the SMS, it is never actually authenticated.
Various OTP Vendors
Contrast this with LoginTC, which does authenticate the device. We use several different methods to ensure that the token cannot be moved to a different device. This provides a strong guarantee that the only device that can be used to authenticate is the same one that the token was originally provisioned on. This means that your mobile device is a second factor with LoginTC, as “something you have” is actually part of the authentication.
The problem is that OTP was never intended to provide a second factor. OTPs were invented to prevent replay attacks in the days when most network communication was unencrypted and sniffing of passwords was a much bigger problem than it is now. The thinking went that if you included a variable part in the password, then even if it did get captured from the network, the attacker couldn’t reuse it in a future session. OTPs don’t protect against Man-in-the-Middle (MITM) attacks either, so an attacker can still take over a connection where a user has sent an OTP. These days, SSL/TLS is used to encrypt network traffic and prevent MITM attacks, so these threats are greatly reduced, and OTPs are no longer needed to prevent replay attacks.
OTPs are Inconvenient
Using OTPs requires changes in the application they’re protecting, and introduces several limitations. To use OTPs, users need to copy them from whatever device recieves or generates them into the login form. This requires a change in the UI of the application to allow users to enter OTPs in addition to any other information. Additionally, since the user is required to copy the OTP from their device to the login screen, it must be a short printable string. This impedes flexibility, leading to reduced security in OTP implementations.
LoginTC Decide Phase contains contextual information about the authentication request
LoginTC does authentication entirely via a wireless secure channel, making it easy to plug in to existing systems without changing UI. With LoginTC connectors, existing systems don’t need to be modified at all to use LoginTC. We also provide more context directly inline with the authentication, letting users see details such as the IP address and location of the originating login attempt, or details about the transaction being authorized. Freed from the limitations of using OTPs, we offer better security that is able to adapt and respond to new threats as they appear, all without inconveniencing the users.
Conclusion
If you want true two factor authentication, stay away from OTPs. You won’t be adding a second factor to your authentication, but you will be inconveniencing your users and complicating your existing login process. LoginTC offers improved security, a better user experience, and easy integration into your existing infrastructure.