OTPs as Second Factor - Strengths and Weaknesses

OTPs as Second Factor

Strengths and Weaknesses

Mark Zeman
by Mark Zeman
on October 21, 2021
time to read: 7 minutes

Keypoints

How to profit from One-Time-Passwords

  • One-time-passwords are simple and can be easy to use
  • SMS-based "mTAN" is vulnerable to SIM-swapping and interception
  • App-based OTPs are better but can still be phished
  • passwordless Auth is the long-term solution

In his Tomaso Vasella lays out the basic idea of passwordless authentication, explaining that while multi-factor authentication increases security, it is important to keep the strength of these factors in mind. For a while now, we have been recommending not to use SMS-based tokens (also called mTANs) as a second factor, as they are vulnerable to SIM-swapping attacks, anticipating the NIST moving them from Restricted to Deprecated. Instead, time-based one-time-passwords (TOTPs) or hardware U2F (universal two-factor) tokens are recommended.

As the name explains, one-time-passwords can only be used once, which mitigates some of the weaknesses of traditional passwords. However, they also pose some additional challenges. In the most common usages, they are not used on their own but as a second factor for a traditional password or as a way of authenticating transactions. In these schemes, OTPs can be pre-generated, transmitted to the user out-of-band (by SMS, for example) or derived from some secret. All of these methods come with their own pros and cons and in practice, either out-of-band delivery or the derived version of OTPs are employed, as storing a list of pre-generated OTPs has proven too cumbersome and error-prone for the end-users.

For the out-of-band delivery, the user registers a way to contact them, like a phone number, and the authenticating party sends the OTP through this secondary channel. This relies on the security of the phone network and the end device of the user, but in this case, it is a secure way of utilizing OTPs. The actual password can then be randomly generated and does not need to rely on any shared information, as the OTP itself is the shared information. If used for transaction authentication, this shared information can also include details of the transaction to be verified, which allows for checking against hidden manipulation of the transaction. When delivered through SMS, this is also known as mTAN or mobile Transaction Authentication Number, although the TANs can also be alphanumeric. Some banks have switched to using an app and delivering the TAN through push notifications, which strengthens the method but we’ll get to that a little later.

For derived passwords, time-based derivation is the most commonly employed variant today. TOTPs are passwords of length 6-10 (although 6 is the default and most common) that are generated by hashing a secret key and a time-based counter in 30-second intervals. The secret is known both to the server and the user (or at least the device the user uses to generate OTPs) and must be protected against attackers. Being only 6 digits long, the OTPs are weak to brute-forcing, though in practice that is easily mitigated by either using rate-limiting or limiting the amount of attempts possible. The short length of the OTPs makes them relatively convenient to use, and as the algorithm is not very complex, it can be implemented in small hardware tokens into which the secret is pre-loaded. Another common way to share the secret is to display it as a QR-code which is then scanned by a smartphone app that then acts as the generator.

How can they be attacked?

So far, that sounds great. Unfortunately, SMS-delivery of OTPs, as nice as it is for the user, has come under attack and is considered Restricted by NIST. A restricted authenticator should only be used with all risks considered and a second, non-restricted authenticator must be provided, if one wants to follow the NIST’s guidelines correctly.

In particular, for SMS-based delivery of TANs, multiple ways to attack the authentication have been found. A weakness in the system for sending SMS was successfully used to intercept SMS and redirect transactions in Germany in 2017, after the vulnerability was discovered in 2014. SIM swapping attacks have also been repeatedly observed in the wild. In these cases, the attacker convinced the service provider to create a new SIM for a certain phone number and used the window between the creation of the new SIM and the discovery that this was not authorized by the user to intercept SMS and bypass the OTP. Lately, there have been more sophisticated efforts targeting such OTPs, from malware infecting both the PC and the smartphone and stealing the info as it is received by the user to social engineering attacks. Most recently, KrebsOnSecurity reported on services that automate the social engineering aspect and pretend to be a legitimate source asking for an OTP, getting the user to reveal it to an attacker.

While for TOTPs and push-based TANs, SMS interception is not relevant, malware on the smartphone can possibly intercept the former and likely the latter and social engineering can still convince users to provide them. TOTPs are somewhat resistant to social engineering, as they need to be utilised in a short timeframe but that is not a problem for a prepared attacker.

Additionally, none of the various ways of using one-time-passwords technically fulfills the requirement of being a different factor by itself: They are all just a second “thing the user knows”, a second password, as the name says. Delivering TANs through push notifications comes close but still falls short – it goes to a registered device, but ultimately the TAN is still the thing that matters and is “something to know” and can be passed on in a social engineering attack.

WebAuthn and the passwordless future

This brings us then to FIDO2 and in general to passwordless authentication. FIDO2 was developed, amongst other things, to provide a proper second factor, one that is not just a second “thing the user knows” and that cannot be intercepted and socially engineered like an OTP. They do this by cryptographically tying the authenticator – a USB key or a smartphone, typically – to the identity as well as to the site. There is no more OTP that can be entered on a lookalike domain: If the domain is not correct, the authenticator does not recognise it and will not provide any information. Similarly, there’s no code to pass on to someone over the phone, as FIDO authenticators must be physically near the computer used for the login, either through USB, NFC or Bluetooth connections. In this way, a FIDO2 authenticator is truly something the user has, rather than something the user knows.

The promise of FIDO, credit: The FIDO Alliance

Universal Second Factor (U2F) and WebAuthn are also terms that often come up in this context. They are components of FIDO, where U2F specifies a standard for supplying a second factor and WebAuthn is the Javascript API that is to be used to benefit from FIDO2. They can be used to enable secure passwordless authentication or for multi-factor authentication but either way, they bring security to a higher standard than either traditional passwords or one-time-passwords manage to achieve.

The biggest problem with this approach is the loss of an authenticator. The intended countermeasure is to allow multiple authenticators, making the loss of any one of them non-catastrophic. In practice it is unfortunately common for only a single authenticator to be allowed, requiring a full re-verification of the user – or a recovery method that then undermines the security of the login.

Conclusion

Even though it is not going to become the prevalent form of authentication for a long time yet, for high-security applications passwordless authentication is already a viable choice and one that should be provided whenever possible going forward. In the end, a passwordless approach is more comfortable and more secure and should be enable just for that alone.

About the Author

Mark Zeman

Mark Zeman has a Master of Science in Engineering with focus on Information and Communication Technologies at the FHNW. He was able to transform his passion of information security to his focus since 2017. During his bachelor studies he worked for an email security company. (ORCID 0000-0003-0085-2097)

Links

You want to test the strength of your enterprise regarding malware attacks?

Our experts will get in contact with you!

×
FONES Minimum Standard

FONES Minimum Standard

Mark Zeman

OWASP Core Rule Set

OWASP Core Rule Set

Mark Zeman

totemomail

totemomail

Mark Zeman

You want more?

Further articles available here

You need support in such a project?

Our experts will get in contact with you!

You want more?

Further articles available here