Dropbox supports Google Authenticator, which means it supports Yubico Authenticator

[brendanhoar]

Yubico Authenticator is a workalike for the Google Authenticator app which adds a feature to securely store the keys used for HOTP/TOTP generation in the smartcard chip of the Yubikey NEO devices (instead of directly on the user device). There's a desktop version, which accesses the smartcard chip via USB and an android version which access the chip via NFC.

Looking at the Dropbox two-factor instructions here, Google Authenticator support is mentioned as supported, which means that Yubikey NEO hardware devices are therefore supported. https://www.dropbox.com/en/help/363

I therefore suggest adding a checkmark for Hardware Token.

This is one example that jumped out at me, there may be others.

Thanks. Brendan

[smholloway]

I'm in favor of keeping twofactorauth.org in-line with the service's docs--that is, we check only the boxes mentioned in the service's docs. We should only check capabilities that Dropbox. Users won't know that they can use Yubikey in place of Google Authenticator, so if we include an undocumented hardware option we lose credibility for having bad information.

There are a number of other providers that can replace Google Authenticator (e.g., they implement RFC6238 and RFC4226). I don't think twofactorauth.org can fairly display that information. Perhaps you could make a pull request for a new page describing OTPs and the myriad hardware and software solutions that can replace Google Authenticator.

[brendanhoar]

Thanks.

I've contacted Dropbox to suggest they add explicit mention and links to yubico authenticator. Support has passed my request to the development and documentation team. If they include it, I will update this Issue and we can re-examine if that clears the bar for hardware token support.

But you're definitely right about the issue. This does bring up a complex set of questions regarding what the hardware token column means (or will mean) in the context of the now several methods of user-initiated storing of network-delivered U2F, HOTP/RFC4226 and TOTP/RFC6238 tokens when the secrets can alternately be stored in software (not really good), device-specific secure enclaves (good) and external hardware tokens (good).

I'll go through the repository's issue log to review previous discussions of this topic to get a feel for the project community's position on the emerging trend of hardware tokens that allow secrets to be securely stored by the end-user. Availability of these device are, in my opinion, an important step in uptake of hardware tokens for TFA.

[mxxcon]

@brendanhoar For lack of a better solution and limitations of hosting using statically cooked pages, a tagging system might be the most flexible, informative and potentially could address all/many corner cases we come across. But so far nobody tackled this yet. If you have any other ideas, do share with us.

[RichJeanes]

I think this falls under the same discussion we had about Google Auth vs Authy support when software implementations had their own columns. Authy supports anything that uses TOPT hence anything that supported GA, also supported Authy. I think that just because it supports Yubikey OTP, does not mean it is a hardware solution. Using a Yubikey for OTP generation requires additional software to setup and use, therefore (IMO) falls under software implementation. If we say this is a hardware solution, then so is GA because it stores the secret key on my phone's hardware (the same way Yubikey OTP stores the secret key on the USB device). I think that hardware should refer to a dedicated OTP device provided by the site/company or things like FIDO devices (https://fidoalliance.org/specifications).

[Carlgo11]

I agree with @RichJeanes

[brendanhoar]

Regarding @RichJeanes' argument:

Reading over what I've written, I hope my response comes across as a reasonable argument and not too pedantic. I am trying to be clear about the secret key storage and cryptographic operations that occur when using Yubico Authenticator and the Yubikey NEO (vs. just using Google Authenticator).

We can agree that RSA has to use software at some point to load their TOTP/HOTP tokens onto the hardware they sell. Does that make RSA tokens a software solution? No, of course not. It shouldn't matter where and when the secret key is loaded onto the device, as long as the secret key is loaded and stored in a secure manner. Right?

Assuming we agreed above...can we agree on a definition of "hardware token"? Something like: a piece of hardware that a) stores one or more secret keys, b) generates OTPs or equivalent based on the secret keys and c) does not provide any method to read the secret key back off of the hardware.

If that is the case, then it follows that...

RSA = hardware token, because it stores the secret key on secure hardware and performs all cryptographic functions on this separate hardware.

Google Authenticator (GA) = software token, because it stores the secret keys on the filesystem and performs all cryptographic functions on the host that it runs on.

Yubico Authenticator (YA) = hardware token, bridged by software. The Yubikey NEO is supported by YA which provides the initial secret key loading, user interface and I/O. YA retrieves the secret keys from a barcode or via user input and immediately stores the secret key onto the secure Yubikey hardware, erasing the secret key from memory, never having stored the secret key on the filesystem. There is no method to read the secret key back from the Yubikey, as it is a specialized security device (e.g. not flash storage). All cryptographic functions occur on the Yubikey and the generated OTPs are sent back to YA for display via NFC or USB. YA also provides clock support since the Yubikey doesn't have a clock/battery and requires that info to be passed to the Yubikey for TOTP generation when it asks for a TOTP code.

Also, ignoring YA entirely, the Yubikey hardware allows you to overwrite either of the two classic Yubikey OTP slots with HOTP/TOTP generating secret keys (6 or 8 digit). If you store an HOTP config, generating the HOTP credential doesn't require any software support other than USB keyboard compatibility. The TOTP credential requires a small helper app (YubiTOTP) to send the current time to the device since, again, the device has no internal clock.

One could load a dropbox secret key onto a Yubikey and generate codes directly without using YA, but because it is TOTP and not HOTP, you'd still need the YubiTOTP app to send the datetime info to the Yubikey. If Dropbox had generated a request for a HOTP implementation instead, no software would be required.

I suppose this can be boiled down to: does the fact that a Yubikey has no battery/clock mean that it will never be considered a hardware token usable for generating TOTP credentials, even though secret key storage is on and cryptographic operations are performed on the Yubikey itself?

Brendan

PS - current Yubkey NEOs support FIDO/U2F. Google appears to be the only large provider that supports U2F as of right now, so it's not salient to the current Dropbox issue.

[RichJeanes]

I understand what you're saying, but I'm trying to consider a user perspective here. To the user, their smartphone is not considered a piece of hardware solely for generating OTPs, it is the software that does the job. If I have a hardware token that has a sole purpose of generating OTPs, then it is the hardware that does the job. If my hardware token connects to the computer and hands the OTP to the site login for me, then it is the hardware that has done the job (on a technical level, I suppose this would be vs regarding the OS as having done the job). However, if my hardware token connects to the computer and this computer HAS to have special software installed, then it seems the purpose of the hardware (again, from the user's perspective) has been defeated. I can no longer access my accounts independent of whatever hardware I happen to be using. I have become reliant on the software.

[smholloway]

Hmmm, Yubikey is trickier to classify than I realized.

Does some version of Yubikey require special software on the host machine?

From https://www.yubico.com/support/faq/:

Do I need to install anything on my computer to use the YubiKey? YubiKey does not require drivers, client software, or batteries.

[Carlgo11]

@smholloway No it does not require you to use special software for the main usage however Yubikey is suposed to work with time based OTP like Google Auth as well. That requires special software. There are many ways to use the Yubikey and most of them are "hacks" (3rd party software to tweek the Yubikey).

So for a conclusion, no the core features of Yubikey doesn't require any special hardware.

P.S there are many versions of Yubikeys. I cannot speak for all of them since I only have one.

For more information about the Yubikeys and Yubico's software go to: https://www.yubico.com/products/

[RichJeanes]

The main point of discussion seems to come down to this. Taken from https://www.yubico.com/products/yubikey-hardware/ Some Yubikey hardware can be used for TOTP, but must be "assisted" by software.

Taken from https://www.yubico.com/products/services-software/personalization-tools/

The YubiKey has 2 “slots” for credentials. By default, we program slot 1 with a YubiCloud credential. The YubiKey personalization tools allow you to add a new credential to the second slot, or even overwrite the credential in slot 1.

[smholloway]

I like @RichJeanes distinction--if Yubikey works through software on your computer, it fits my definition of software.

Any guidance on how we police when Yubikey is hardware?

[Carlgo11]

No we should not add software

[jamcat22]

Yubikeys are a little bit tricky to classify (I have one).

The way I see it is this:

• If a website supports a hardware-specific type of 2FA (ex: an RSA token or the actual Yubikey API [not TOTP/HOTP]), where the hardware DOES NOT have to be assisted by software (ex: you do not need to use a program to configure the hardware), then that should be classified as hardware.
• If a website supports a software-specific type of 2FA (ex: Garena's custom token app) or a software-driven protocol (ex: TOTP/HOTP), then that should be classified as software.
• If a website supports a software-driven protocol (ex: TOTP/HOTP) that can be used on some pieces of hardware (ex: a Yubikey), but DOES require assistance from software OR IS NOT supported out-of-the-box by the hardware, then it should be classified as software.

So:

• A Yubikey should be classified as hardware if the website uses the Yubikey API (meaning it has direct support for the Yubikey) or (in the case of the FIDO and NEO Yubikeys) it utilizes the U2F hardware protocol.
• A Yubikey should be classified as software if the website uses TOTP/HOTP or another protocol the Yubikey supports, but does not support out-of-the-box or is not restricted to hardware.

[jamcat22]

I think we should not add the hardware tag to Dropbox.

[smholloway]

Sounds good to me, @jamcat22.

[Carlgo11]

Should I close this issue then?

[RichJeanes]

I think it sounds like we've hit a pretty solid consensus on this one. Should we look into setting clear definitions of each category in the project readme? I think it's going to be kinda wordy no matter what just due to the nature that these are admittedly mildly arbitrary definitions we're creating for the purpose of this project.

[brendanhoar]

@RichJeanes - understood. And yes, assistance is required for TOTP (which consists of passing the current date/time to the device). Granted, if the bar is "requires software to be used", then I suppose all smart cards would not be considered hardware tokens for 2FA, just software 2FA, from a user point of view.

@smholloway - For TOTP configuration, please see: http://www.yubico.com/wp-content/uploads/2014/02/Yubico-TOTP-Setup.pdf

All -

Yes, I concur the ticket can be closed.

Under the current project guidelines of "a token can be called a hardware token only if it does not require additional software", the Yubikey modes that actually fit that particular requirement are: Yubikey OTP, Yubikey VIP (aka Symantic VIP) and 6 or 8 digit HOTP generation. If a service supports any one of those (and is able to provide a secret key to the user for the HOTP case), then the yubikey can be considered a hardware token.

Yubikey's TOTP support does not fit that criteria. Nor does Challenge-Response. Technically U2F doesn't either, because it requires you install a browser that has added support for it (most recent release of chrome only so far).

[Opinion section: I hope that in the future we can consider categorizing tokens more along the lines of level of resistance to attack instead of what appears to be an taxonomy that (I think) came about due to a large number of software-only solutions making too-strong claims about their suitability for 2FA purposes.

I'd (currently) rank level-of-security/resistance-to-attack in this order: a disconnected crypto token (e.g. RSA) is slightly more secure than a connected crypto token (e.g. Yubikey NEO, powered by NXP) is more secure than device-integrated crypto chips (e.g. apple's secure enclave / samsung's knox, both powered by NXP) is more secure than an application that stores secure keys (encrypted) on a phone/computer (e.g. google authenticator).]

---

I've included an overview of the capabilities of the current Standard Yubkey and Yubikey NEO, just for future reference, below.

Standard Yubikey behavior - to generate keystrokes for an OTP passcode by masquerading as a USB keyboard device. Touch for credential #1. Long press for credential #2. Two credentials maximum.

The Standard hardware supports:

1. Unassisted: their initial service "Yubikey OTP" is sometimes referred to as "Yubicloud OTP", which is a home grown hash-based OTP, specially encoded so that international keyboard differences don't cause problems. All keys except VIP keys come with slot #1 preloaded by Yubico, containing a secret key that only they know and only they can validate against.
2. Unassisted: OATH-HOTP - you can load a secret key. 2.5 Unassisted: Yubikey VIP - Pre-loaded with a Symantec VIP secret key in slot 1. Symantec has a copy of the secret key and associates it with device serial # which will be used for registration. It's a pre-loaded version of the OATH-HOTP configuration.
3. Assisted (clock): OATH-TOTP - you can load a secret key, but you must use a helper app to pass the datetime to the device so that it can generate the correct OTP.
4. Assisted (challenge): Challenge-Response using HMAC-SHA1 or Yubikey-OTP algorithms where a challenge is passed to the device before OTP generation: I'm not very familiar with this configuration, but I suspect that the OATH-TOTP support above actually utilizes the HMAC-SHA1 version of Challenge-Response. Interestingly, there are companies out there with unconnected hardware tokens that presumably do something very similar requiring user entry of the challenge instead of software assist, e.g. http://www.safenet-inc.com/multi-factor-authentication/authenticators/one-time-password-otp/gold-challenge-response-token/
5. Unassisted: Static Password - whatever you want, unchanging, mostly not very useful.

Their Yubikey NEO hardware supports everything above, but instead of homegrown hardware, it uses an NXP smartcard chip running javacard (as do some other smart cards out there) and the ability to both be powered and interface via USB or NFC. They show up as USB composite devices (multiple HID devices + smartcard reader + smartcard).

So, via the preloaded javacard apps, the NEOs also support the following features on both desktop and mobile and via USB or NFC:

1. YubiKey OTP applet - All of the above Standard functionality via USB, now also available via NFC.
2. YubiOATH applet - space for dozens of HOTP/TOTP credentials (this is a separate secure key store from the slot 1/slot 2 mentioned above).
3. Yubico U2F applet - FIDO U2F support.
4. OpenPGP applet - standard for PGP/GPG smartcard support.
5. Yubico PIV - standard for corporate/government Privilege and Identification Card credentials.

B

[mxxcon]

@jamcat22 You don't think that these https://gear.blizzard.com/index.php/default/authenticators.html should be classified as hardware?

[jamcat22]

@mxxcon I'm not saying that at all. I'm saying that the software authenticator shouldn't be classified as hardware.

I'm just using Blizzard as an example for a proprietary software app. The only other examples I can think of are Trion (which has hardware), Garena (which does not) and OneID (which does not).

[jamcat22]

Thanks for bringing that up. I'll go ahead and change my example to Garena.

[RichJeanes]

Closing for house keeping.