How to profit from One-Time-Passwords
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.
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.
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 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.
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.
Our experts will get in contact with you!
Our experts will get in contact with you!
Further articles available here