One-Time Passcodes or U2F Tokens? Which One Is Yours?

If you care a little about user data protection, then you might well have heard about services promoting security features such as TOTP, U2F and OTP with Yubikey. Don’t worry, you aren’t the only one who doesn’t know exactly what these mean, but if you want to maximize the protection of your online accounts, then it’s important to know the difference between them and the security that they provide.

The Second Layer of Security

Every time news of a security breach appears it highlights how weak the static, single-layer security of a username and password combination is nowadays. It may be due to the advancements of hacking techniques and technologies or just the bad habit of using weak, easy-to-guess passwords when we shouldn’t.

But the addition of a second factor – as in possession of a token, code or something else that only the rightful user can know – seeks to address the demand for more secure account protection. Time-based One-Time Passwords (TOTP), One-Time Passwords (OTP), and Fido’s Universal 2nd Factor (U2F) provide a solution to this rising issue.

What the three methods have in common is that they all require a piece of information that only the rightful user has, and in more technical terms this is based on a challenge/response model. This is what ultimately provides access to the account, even if someone else knows the username and password.

Time-based One-Time Password (TOTP)

At the core of TOTP is the clock, which is used as the challenge value. The most popular service based on this solution is the six-digit passcodes displayed in the Google Authenticator app. Since it is time-based, it requires synchronization with the service that is applying this security layer. What happens is that a cryptographic key is created when, for example, you enroll your Dropbox account with Google Authenticator. The clock starts at 1/1/1970 (Unix epoch) and the six-digit codes – AKA the challenge value – are valid for 30 seconds.

When a user tries to log into their Dropbox account, the Authenticator app will show a six-digit passcode that matches Dropbox’s user database thanks to the synchronized ‘clocks’. Unfortunately, this method carries a few weak points that can be exploited by any knowledgeable hacker, in particular:

• If the user key is compromised, the hacker will be able to generate a valid response code.
• The key created when a user enrolls a service into TOTP requires storage and protection.
• The cryptographic key transferred to Google Authenticator can be intercepted.

One-Time Passcodes With Yubikey

There is another way of generating one-time passcodes: using a hardware token. One such example is Yubikey, which is currently sold as an “unphishable” product. Unfortunately, that’s not the case due to a security vulnerability found in Chrome’s WebUSB feature, although the flaw itself isn’t in the security system that Yubikey uses.

Yubikey is based on the combined use of counters, timers, and random value generators, as well as the 128-bit length cryptographic key that is created by Yubiko and stored directly on the device at the moment of manufacturing the device. This hardware token is one of the best commercially available options that users have if they don’t refrain from the hassle of two-factor authentication.

The token is inserted in the computer’s USB port and the user then touches the device to generate a one-time password. Of course the token must be registered with the service being accessed and the 12-byte user identifier stored as part of the user profile.

Fido’s U2F

This protocol – developed by FIDO – was created as an answer to security attacks against OTP schemes. The U2F protocol is based on standard public-key cryptography techniques and involves the client in the authentication process. When registering a new online account via a web browser, the client is the browser in this case.

It is at the point of when a user registers for a new online service that public and private cryptographic keys are generated. The private key is then stored on the registered device, and when a login attempt is made the account successfully opens if the challenge sent by the service provider provides the correct response, which in this case is a signature from the private key stored on the registered device. This method seeks to ensure only authorized devices – and therefore the rightful account owner – have access to the requested online service.