6 ms·

Compared to Google Authenticator app, YubiKey (a) makes hardware-based OTPs as opposed to time-based OTPs (does that offer stronger security?) and (b) can be us

Compared to Google Authenticator app, YubiKey (a) makes hardware-based OTPs as opposed to time-based OTPs (does that offer stronger security?) and (b) can be used as smart card in GnuPG solutions. It being a separate piece of plastic might arguably be another advantage, if we assume that most people are more likely to lose their phone than their keyring. It’s interesting: apparently[0], YubiKey is Google’s initiative and the company itself uses YubiKeys internally. [0] http://www.forbes.com/sites/amadoudiallo/2013/11/30/google-wants-to-make-your-passwords-obsolete/ http://www.forbes.com/sites/amadoudiallo/2013/11/30/google-w...

e12e 11y ago
> Compared to Google Authenticator app, YubiKey (a) makes hardware-based OTPs as opposed to time-based OTPs (does that offer stronger security?) If I understand the various OTP implementations correctly, they are essentially the same, trading a time-counter for use-counter. The non-time OTP will give you ds1, ds2, ds3 -- where dsX ("derived secret X") is derived from shared-secret+X, while the time-based OTP will give you dsT1, dsT2 ... derived from shared-secret+TimestampX. The former is a little more secure, as you need to allow for some drift. And having a proper 128 bit shared secret is probably more secure than something derived from a crackable password/pass phrase. But AFAIK they're both vulnerable to the shared secret being compromised on the server-side and/or cracked (if it's possible to brute force). I don't recall the exact details of the TOTP-spec, but in general I think the derived-secret/otp essentially boils down to: truncate(hmac(shared-secret,counter)) where counter is either a timestamp, or a sequence. If the counter is actually a sequence of used passwords(1,2,3...N), the server can store just N passwords (usable for N logins), and cross them off after use -- so no need to store the shared secret on the server. For TOTP the server needs the shared-secret in order to generate a few +/- values to match against what the client supplied. In both cases you could use a sniffed one-time password to try and guess the shared-secret, if you can know/guess the counter. The risk for a 128 bit random key is obviously somewhat less than if the shared secret is "hunter2" (modulus stretching etc).
Yubi_David 11y ago
The YubiKey's main strength is that users can configure it to meet their own needs; YubiKeys have 2 configurations slots which can be independently programmed for the Yubico OTP or OATH-event based modes, as well as Challenge-Response or a static password. Further, with a small app on the host machine, the YubiKey can provide OATH- time based codes, identical to Google Authenticator. The newer YubiKey versions also support the new U2F Protocol used by Google. The YubiKey is developed and owned by Yubico - Yubico worked with Google to develop the protocol which would become U2F for Google's internal use.
joshka 11y ago
YubiKey does TOTP (time based OTP) by storing the shared secret on the key and having the connected system pass in the system time. It's more secure as the shared secret is write only, compared with having google authenticator on the phone storing the shared secret in your phone's storage. See http://www.yubico.com/wp-content/uploads/2014/02/Yubico-TOTP-Setup.pdf http://www.yubico.com/wp-content/uploads/2014/02/Yubico-TOTP...

e12e 11y ago

> Compared to Google Authenticator app, YubiKey (a) makes hardware-based OTPs as opposed to time-based OTPs (does that offer stronger security?) If I understand the various OTP implementations correctly, they are essentially the same, trading a time-counter for use-counter. The non-time OTP will give you ds1, ds2, ds3 -- where dsX ("derived secret X") is derived from shared-secret+X, while the time-based OTP will give you dsT1, dsT2 ... derived from shared-secret+TimestampX. The former is a little more secure, as you need to allow for some drift. And having a proper 128 bit shared secret is probably more secure than something derived from a crackable password/pass phrase. But AFAIK they're both vulnerable to the shared secret being compromised on the server-side and/or cracked (if it's possible to brute force). I don't recall the exact details of the TOTP-spec, but in general I think the derived-secret/otp essentially boils down to: truncate(hmac(shared-secret,counter)) where counter is either a timestamp, or a sequence. If the counter is actually a sequence of used passwords(1,2,3...N), the server can store just N passwords (usable for N logins), and cross them off after use -- so no need to store the shared secret on the server. For TOTP the server needs the shared-secret in order to generate a few +/- values to match against what the client supplied. In both cases you could use a sniffed one-time password to try and guess the shared-secret, if you can know/guess the counter. The risk for a 128 bit random key is obviously somewhat less than if the shared secret is "hunter2" (modulus stretching etc).

Yubi_David 11y ago

The YubiKey's main strength is that users can configure it to meet their own needs; YubiKeys have 2 configurations slots which can be independently programmed for the Yubico OTP or OATH-event based modes, as well as Challenge-Response or a static password. Further, with a small app on the host machine, the YubiKey can provide OATH- time based codes, identical to Google Authenticator. The newer YubiKey versions also support the new U2F Protocol used by Google. The YubiKey is developed and owned by Yubico - Yubico worked with Google to develop the protocol which would become U2F for Google's internal use.

joshka 11y ago

YubiKey does TOTP (time based OTP) by storing the shared secret on the key and having the connected system pass in the system time. It's more secure as the shared secret is write only, compared with having google authenticator on the phone storing the shared secret in your phone's storage. See http://www.yubico.com/wp-content/uploads/2014/02/Yubico-TOTP-Setup.pdf http://www.yubico.com/wp-content/uploads/2014/02/Yubico-TOTP...