I use the Yubikey Neo as a smartcard + gpg for ssh private key logins[1], U2F with Google[2] accounts, and their OTP for things like LastPass[3].
I wrote some patches for KeepassX to use the Yubikey to derive the encryption key (completely offline)[4] but unfortunately the maintainer has zero interest in merging them.
I'm quite curious, what's the contingency plan in case the Yubikey gets stolen? How do you deal with things like email encrypted to the key you've now lost?
I use a Yubikey for my Google accounts. They did a great job integrating it as a multi-factor auth option. It's a lot easier than punching in numbers from an SMS/Google Authenticator.
My Yubikey feels like a natural member of my key ring! I love it.
It's only supported in chrome, with other browser support at least 6 months away (guess). After getting a test webapp to work with u2f tokens on chrome I wouldn't say it's easy. YMMV.
I bought a YubiKey so I could use it on my laptop with LastPass. Works fine. One day I grabbed my iPad and opened the LastPass app and it hit me... how am I going to authenticate with a YubiKey on an iPad. It took my password and then just worked.
I guess I misunderstood. I thought that once I enabled two-factor auth for LastPass, it'd require that no matter what. Nope, just open the iPad app and no two-factor required.
That depends on your configuration. LastPass supports per-device exceptions, so that you can allow login from devices without USB ports. I'd suggest checking for the device settings in your LastPass vault; mine are reasonably restrictive :).
You can configure particular devices to allow login without needing the YubiKey. Every device other than my iPhone requires my YubiKey for LastPass, and my iPhone requires my fingerprint. Reasonably secure, though I wish Apple would add NFC so the YubiKey Neo can work with it.
I own a YubiKey Neo. My plan was to use it with KeePass/OATH HOTP (I used it with master password only on my three main devices). Turns out the OtpKeyProv plugin won't work on the OSX version I used before (MyPass Companion, switched to MacPass since because well it's on github). So for now I'm using the non-native Windows version with Mono.
Alas synching between different machines isn't easy (counter gets out of synch) and I'm not all that comfortable with keeping the databse in my owncloud.
If anyone has a good suggestion for a crossplattform (Xubuntu, OSX, Android), synchable and FLOSS OATH HOTP password storage solution that doesn't rely on 3rd party cloud storage I'm all ears. Not exactly a security expert but I feel that's the setup I want :)
I could fallback to challange/response and that would fix some issues but be less secure.
I'm in the same boat; didn't work at all on OSX when I tried. In fact, even on windows the plugin somehow failed to install properly, and I never even managed to 'register' the key. The support helpfully told me to raise a ticket (thanks, I'm a /customer/ not your beta tester)
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.
> 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).
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.
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.
I use too the Yubikey Neo as a smartcard, but not with the GPG applet, rather with the PIV applet. As such, to connect to my most secure servers, my Yubico is mandatory and as such it's just impossible to bruteforce your way in.
I use the GPG applet ...well...for GPG.
However, I'm still looking for a cheap way to do fingerprint (rather than typing your PIN) authentication.
Does anybody have heard of a fingerprint token which works with Linux AND Mac OS X ? Or is it possible to have a fingerprint reeader as some sort of proxy ?
Second question, I wanted to use the Yubico NEO as a smartcard token with a TrueCrypt fork, but the Truecrypt source code has really specific requirements for the object they can store on a smartcard (buggy requirements if you ask me) and as such it's not possible to use the Yubico as a physical decryption key for encrypted volume.
Does anybody have a suggestion for an other working solution ?
Just got some of these to secure ssh login to our infrastructure. Work great but be prepared for a bit of a hassle especially if you've never used anything like a smart card before. Finding simple answers to how to use as an rsa smart card device for ssh took a few hours and getting it into the right mode took some obscure commands.
If you have to get an OTP multiple times a day—say to ssh into a prod server—you quickly learn how laborious it is having to take your phone out of your pocket, unlock it, find the Google auth app, find which OTP you're looking for then finally transcribe it without any errors. Pressing a key combo/tapping the yubikey (depends on the model you have and its settings) is much faster.
To me, not having a yubikey would be like not being able to use cmd-C/V to copy/paste and having to use the system menu every time instead.
Because U2F is much safer than TOTP. TOTP is still sensitive to phishing: the MITM could just ask for the TOTP code and forward it. This is not possible with U2F, since only the original site has the key handle that is necessary to initiate the challenge-response.
On the upside, Google Authenticator has access to an accurate RTC.
On the downside, your encryption secret is available "in the clear" in the form of a TOTP token that is loaded into the app. You are highly vulnerable during these moments. If an attacker gets a copy of the TOTP token, they can generate the six digit numbers as easily as you.
You can associate multiple U2F keys with a Google account. Since the Yubico's U2F key is really cheap (I think ours were ~15 Euro a pop), it doesn't hurt to associate another key and put it in a safe somewhere.
This looks interesting, but I don't totally understand how it works. How is the key changed every time on the server? It looks like it requires server side support.
I have a few of their basic model keys. They have implemented OATH-HOTP as well as their own OTP scheme and HMAC-SHA1 challenge-response. You can also embed a static password. The keys have two slots and both of them can be used for any of the supported schemes.
They have some fancier keys that support a 'universal 2 factor' standard which I think they may have had a hand in creating.
I've used mine in OATH-HOTP and HMAC-SHA1 along with KeePass to do two-factor on my password db. You do need a server-side or peer component to initially sync with to do OTP or challenge-response.
[+] [-] 2bluesc|10 years ago|reply
I wrote some patches for KeepassX to use the Yubikey to derive the encryption key (completely offline)[4] but unfortunately the maintainer has zero interest in merging them.
[1] https://www.yubico.com/2012/12/yubikey-neo-openpgp/
[2] http://googleonlinesecurity.blogspot.com/2014/10/strengtheni...
[3] https://www.yubico.com/products/services-software/personaliz...
[4] https://github.com/keepassx/keepassx/pull/52 and https://news.ycombinator.com/item?id=7801131
[+] [-] hobarrera|10 years ago|reply
[+] [-] rhinoceraptor|10 years ago|reply
[+] [-] finnn|10 years ago|reply
Other than that, this is cool and I generally really like my YubiKey Neo
[+] [-] artursapek|10 years ago|reply
My Yubikey feels like a natural member of my key ring! I love it.
[+] [-] dguido|10 years ago|reply
https://developers.yubico.com/U2F/Libraries/List_of_librarie...
[+] [-] rmac|10 years ago|reply
You need to include this js: https://demo.yubico.com/js/u2f-api.js
... which isn't really mentioned anywhere. That js file loads an embedded chrome extension and handles all the heavy lifting.
The documentation (if there is any?) fails to mention that your appId has to be https; any http appIds will fail with an obscure error.
[+] [-] codewritinfool|10 years ago|reply
I guess I misunderstood. I thought that once I enabled two-factor auth for LastPass, it'd require that no matter what. Nope, just open the iPad app and no two-factor required.
[+] [-] frio|10 years ago|reply
[+] [-] girvo|10 years ago|reply
[+] [-] Freaky|10 years ago|reply
[+] [-] wiredfool|10 years ago|reply
[+] [-] lwf|10 years ago|reply
[+] [-] kriro|10 years ago|reply
Alas synching between different machines isn't easy (counter gets out of synch) and I'm not all that comfortable with keeping the databse in my owncloud.
If anyone has a good suggestion for a crossplattform (Xubuntu, OSX, Android), synchable and FLOSS OATH HOTP password storage solution that doesn't rely on 3rd party cloud storage I'm all ears. Not exactly a security expert but I feel that's the setup I want :) I could fallback to challange/response and that would fix some issues but be less secure.
[The Yubikey itself is pretty cool though]
[+] [-] buserror|10 years ago|reply
[+] [-] goblin89|10 years ago|reply
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-w...
[+] [-] e12e|10 years ago|reply
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|10 years ago|reply
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|10 years ago|reply
See http://www.yubico.com/wp-content/uploads/2014/02/Yubico-TOTP...
[+] [-] yannovitch|10 years ago|reply
I use too the Yubikey Neo as a smartcard, but not with the GPG applet, rather with the PIV applet. As such, to connect to my most secure servers, my Yubico is mandatory and as such it's just impossible to bruteforce your way in. I use the GPG applet ...well...for GPG.
However, I'm still looking for a cheap way to do fingerprint (rather than typing your PIN) authentication. Does anybody have heard of a fingerprint token which works with Linux AND Mac OS X ? Or is it possible to have a fingerprint reeader as some sort of proxy ?
Second question, I wanted to use the Yubico NEO as a smartcard token with a TrueCrypt fork, but the Truecrypt source code has really specific requirements for the object they can store on a smartcard (buggy requirements if you ask me) and as such it's not possible to use the Yubico as a physical decryption key for encrypted volume. Does anybody have a suggestion for an other working solution ?
[+] [-] api|10 years ago|reply
[+] [-] KNoureen|10 years ago|reply
[+] [-] homakov|10 years ago|reply
[+] [-] lyall|10 years ago|reply
To me, not having a yubikey would be like not being able to use cmd-C/V to copy/paste and having to use the system menu every time instead.
[+] [-] microtonal|10 years ago|reply
https://developers.yubico.com/U2F/Protocol_details/Overview....
[+] [-] sjwright|10 years ago|reply
On the downside, your encryption secret is available "in the clear" in the form of a TOTP token that is loaded into the app. You are highly vulnerable during these moments. If an attacker gets a copy of the TOTP token, they can generate the six digit numbers as easily as you.
[+] [-] sp332|10 years ago|reply
[+] [-] salibhai|10 years ago|reply
[+] [-] microtonal|10 years ago|reply
[+] [-] godber|10 years ago|reply
[+] [-] girvo|10 years ago|reply
[+] [-] falsedan|10 years ago|reply
[+] [-] Zombieball|10 years ago|reply
I have one vltjjenelhnhhkvrnft also.
[+] [-] newman314|10 years ago|reply
[+] [-] reilly3000|10 years ago|reply
[+] [-] rmac|10 years ago|reply
[+] [-] cmbaus|10 years ago|reply
[+] [-] gnoway|10 years ago|reply
They have some fancier keys that support a 'universal 2 factor' standard which I think they may have had a hand in creating.
I've used mine in OATH-HOTP and HMAC-SHA1 along with KeePass to do two-factor on my password db. You do need a server-side or peer component to initially sync with to do OTP or challenge-response.
[+] [-] tacticus|10 years ago|reply
Each side has a seed value which then allows the calculation of what the current value should be.
[+] [-] olefoo|10 years ago|reply
[+] [-] unknown|10 years ago|reply
[deleted]