making security even easier

TOTP replay attack — Yubikey et al.

I have recently stumbled upon several articles with rather clickbait titles stating that some models of FIDO keys were compromised. If you are not aware, this was a successful attempt by Ninjalab engineers to clone the keys stored on NXP A700X, which is used as a component of popular U2F devices, such as the Yubico keys. Leaving the technical details aside, here are the preconditions for a successful attack:

  • The attacker should know the victim’s primary authentication factor (username + password)
  • The attacker should have access to the victim’s U2F key for an extended period (i.e. >5 hours)

As you can see, the preconditions are quite hard to meet, but if the media presents this as a serious vulnerability, this makes me think of a different attack type which does not use any vulnerabilities, exists for many years, can be easily exploited with the same preconditions and is very easy to perform.

I take Yubikey only as an example, but the same “vulnerability” applies to many other FIDO2 devices that have the possibility of using them as TOTP devices.

TOTP on YubiKeys

For TOTP you need an application that can read OATH codes from YubiKeys, since YubiKeys does not have an internal clock

A requirement for this is a special app, Yubico Authenticator, that fills the gap: the app sends the timestamp information from the system it is installed on to the Yubikey, and reads back the OTP generated by its chip. So, the use case of Yubikey as a TOTP generator is different from standalone TOTP tokens — with TOTP tokens, users do not need any additional device or system to log in, with Yubikey this is to enhance security. A risk comparison is shown in the figure below:

Image for post
Yubico Authenticator vs Google Authenticator

So, the main advantage of using Yubico Authenticator in combination with a physical Yubikey over a TOTP App, such as Google authenticator, is that the shared secret is stored on an external device, which is marketed as a more secure solution.

TOTP Replay attack

  • The attacker should know the victim’s primary authentication factor (username + password)
  • The attacker should have access to the victim’s U2F key for an extended period (i.e. >5 hours)

Now, finally to the vulnerability itself — here are the steps:

Table 1. Example: Recorded results of YKOATH replay attack

  • The attacker installs the Yubico Authenticator on a PC, and sets the time to the future, i.e. several weeks from now (for example, 3rd of March as shown on the example above) in the future and records the OTPs generated by the Yubikey stolen from the victim. This can be repeated for several/hundreds/thousands of times as it can be easily automated using YKOATH Protocol and simple scripts (like this one, where Clock argument of OATH struct should be replaced with the “future” timestamps)
  • The attacker returns the Yubikey back to the victim, ideally without the victim even noticing it (this is much easier to implement than with Ninjalab’s attack where they have to physically open the case)

So, again, if the preconditions are met, the attacker gets access to the victim’s second factor and can exploit the vulnerability on the specific date and time (i.e. 3rd of March around 10:00 AM) by logging in using the previously generated OTPs.


Trademarks, quoted texts, photos and other similar content used in this article are property of their respective owners, Google, NinjaLabs, Yubico etc.

<< Go back to the previous page

G+ profile

follow me : github, habrahabr , linkedin
Feel free to contact me directly :
emin --at huseynov --dot com

Other projects

Google authenticator for Citrix StoreFront
Google authenticator for Citrix Web Interface 5.4
MOTP App with QR based enrolment

Not security related