YubiKey – Making secure login easy(yubico.com)
yubico.com
YubiKey – Making secure login easy
https://www.yubico.com/
54 comments
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?
Is it possible to sit down on someone else's computer and trivially use a Yubikey for SSH and git with SSH keys?
The GPG applet only does keys up to 2048 bits :(
Other than that, this is cool and I generally really like my YubiKey Neo
Other than that, this is cool and I generally really like my YubiKey Neo
Maybe you will like the FST-01? It's a free hardware device that can run gnuk, which is a free software smartcard over usb implementation. While it also supports RSA 2048 by default you can upgrade it to use RSA 4096 or even Ed25519 keys with GnuPG 2.1.
Both, the FST-01 and Gnuk are made by one of the GnuPG main developers, gniibe :)
I suggest this as I discarded a Yubikey NEO for one of these and i'm pretty happy.
http://www.seeedstudio.com/wiki/FST-01 http://www.fsij.org/doc-gnuk/
Both, the FST-01 and Gnuk are made by one of the GnuPG main developers, gniibe :)
I suggest this as I discarded a Yubikey NEO for one of these and i'm pretty happy.
http://www.seeedstudio.com/wiki/FST-01 http://www.fsij.org/doc-gnuk/
Yubikey is FIPS-140 certified -- unfortunately, I haven't found anything else usable and/or reasonably priced that is, and the only other usable thing that's actually a smartcard, in the sense that in the absence of bugs you need some very unavailable hardware like a FIB machine, is the PGPcard.
I didn't notice any difference in the usability of Gnuk and the Yubikey NEO. I mean, i had to do the same things for both to configure and use them as they are both are "smartcards". What issues did you found with Gnuk?
I'm interested as for our local work (activism related) Gnuk showed up as the best alternative for price, openess and the possibility if something fails to not have to buy new hardware. Yubikey did the right thing with their latest "put your yubikey in the trash bug" giving a new one, but we don't live in the US and time can be a factor.
But still, Gnuk is far from perfect and the better it gets the better for us. Can you tell me about the issues you had so i can talk with gniibe to see if there are solutions for them?
Thanks in advance.
I'm interested as for our local work (activism related) Gnuk showed up as the best alternative for price, openess and the possibility if something fails to not have to buy new hardware. Yubikey did the right thing with their latest "put your yubikey in the trash bug" giving a new one, but we don't live in the US and time can be a factor.
But still, Gnuk is far from perfect and the better it gets the better for us. Can you tell me about the issues you had so i can talk with gniibe to see if there are solutions for them?
Thanks in advance.
I didn't try gnuk - This is the first time I hear about it.
I was comparing NEO to other tokens I've seen and used - it's not worse, but non of them are as simple as I would like (and no, I don't know how to describe the simplicity I'm after).
Looks like the gnuk is a software implementation - do you trust it not to disclose the private key if it is physically accessible? If you do, why?
I trust the NEO to require more than what your average hacker can use at home - though, of course, I don't trust it against state actors, who probably have the fund and equipment to make any smart card apparatus "talk".
I was comparing NEO to other tokens I've seen and used - it's not worse, but non of them are as simple as I would like (and no, I don't know how to describe the simplicity I'm after).
Looks like the gnuk is a software implementation - do you trust it not to disclose the private key if it is physically accessible? If you do, why?
I trust the NEO to require more than what your average hacker can use at home - though, of course, I don't trust it against state actors, who probably have the fund and equipment to make any smart card apparatus "talk".
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.
My Yubikey feels like a natural member of my key ring! I love it.
FYI anyone can integrate yubikey u2f logins on their website. It's easy, try it out:
https://developers.yubico.com/U2F/Libraries/List_of_librarie...
https://developers.yubico.com/U2F/Libraries/List_of_librarie...
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.
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.
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.
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.
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.
By default "mobile devices without USB ports" can bypass Yubikey authentication. It can be changed in the multifactor auth Yubikey settings.
I've been able to use a yubikey on an ipad2 with the camera connection kit USB adapter, but I don't think that it works on newer iPads.
See also:
https://developers.yubico.com/PGP/ -- OpenPGP/GnuPG support
https://developers.yubico.com/PIV/ -- PKCS certificates
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.
[The Yubikey itself is pretty cool though]
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]
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.
[0] http://www.forbes.com/sites/amadoudiallo/2013/11/30/google-w...
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...
> 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).
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.
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.
See http://www.yubico.com/wp-content/uploads/2014/02/Yubico-TOTP...
See http://www.yubico.com/wp-content/uploads/2014/02/Yubico-TOTP...
https://xkcd.com/538/
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 ?
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.
Thanks but no, google auth can be installed on any mobile device. Why bother with some "keys"
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.
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.
https://developers.yubico.com/U2F/Protocol_details/Overview....
https://developers.yubico.com/U2F/Protocol_details/Overview....
Can you elaborate with attack scenarios how U2F mitm is different? There's no display on youbiky, which means it's the same thing
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.
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.
What happens if you lose or break this thing and you have it configured on lastpass or google login?
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.
You generate backup one time password codes at activation time. Store those somewhere safely. Use them in the event of trouble.
Backup codes, or you do what I did: I bought two, and keep one in a safe place.
My biggest issue with YubiKey is I have to be mindful when picking up my laptop or else I eidlioustrioutnasdillkaoei all over the place.
I am going to go out on a limb and guess you have a YubiKey Nano?
I have one vltjjenelhnhhkvrnft also.
I have one vltjjenelhnhhkvrnft also.
I don't see a good way to use this with an iOS device and 1Password...
The have a NFC version. I wish Apple would be on board...
the rumor is a bluetooth dongle will come out before year end...
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.
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.
The new U2F protocol removes the need to have a central authentication server - the authentication process is just between the U2F device and the authenticating service. For more details, you can see: https://developers.yubico.com/U2F/
iirc they implement https://en.wikipedia.org/wiki/HMAC-based_One-time_Password_A... (or a variant of it)
Each side has a seed value which then allows the calculation of what the current value should be.
Each side has a seed value which then allows the calculation of what the current value should be.
The YubiKey does support the OATH-event based OTPs as described above, but the Yubico OTP takes advantage of the fact users do not need to type in anything to make the OTPs longer and more secure.
Each Yubico OTP has a plain text public ID as the first 12 characters of the OTP. This is used to identify the YubiKey which generated the OTP without having to perform any OTP processing. The remaining 32 characters of the OTP are an AES-128 bit encrypted hash. This hash is made of the Private ID, a string known only to the YubiKey and Authentication server, to further validate the OTP.
In addition to the Private ID, the OTP also contains counters tracking how many times the YubiKey has been power cycled (usage) and how many OTP events it has preformed since it's last power on (session). These counter values are stored in the authentication server and checked for each OTP. If the usage counter is less than the value on the server, or if the session counter is less than or equal to the value on the server, the OTP is rejected as a replay attack.
This means the YubiKey OTP will not get out of sync with the validation server, as well as adding additional randomness to the OTPs generated.
Each Yubico OTP has a plain text public ID as the first 12 characters of the OTP. This is used to identify the YubiKey which generated the OTP without having to perform any OTP processing. The remaining 32 characters of the OTP are an AES-128 bit encrypted hash. This hash is made of the Private ID, a string known only to the YubiKey and Authentication server, to further validate the OTP.
In addition to the Private ID, the OTP also contains counters tracking how many times the YubiKey has been power cycled (usage) and how many OTP events it has preformed since it's last power on (session). These counter values are stored in the authentication server and checked for each OTP. If the usage counter is less than the value on the server, or if the session counter is less than or equal to the value on the server, the OTP is rejected as a replay attack.
This means the YubiKey OTP will not get out of sync with the validation server, as well as adding additional randomness to the OTPs generated.
The client and the server have a shared secret that lets them generate a keystream based on the time.
I don't think the Yubikey is able to generate TOTPs, unless all it is doing is passing the secret to the computer which is then generating them.
Yubikey supports TOTP with OS driver help. Presumably the driver passes the time to the Yubikey to actually generate the TOTP.
https://www.yubico.com/products/yubikey-hardware/
https://www.yubico.com/products/yubikey-hardware/
[deleted]
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