One of our engineers, Paddy Steed, wrote a series of articles on how we each use a Yubikey for SSH, UTF 2FA, and access to 1Password on shared machines when we pair-program. The SSH key is generated on the Yubikey, so it never touches your machine's filesystem.
This flaw only affected generated RSA keys, ECC keys should still be OK. Yubikey provided an excellent service for replacing their products when I went through them. However, I hear the story is quite different if you bought one via Amazon.
> Yubikey provided an excellent service for replacing their products when I went through them. However, I hear the story is quite different if you bought one via Amazon.
I bought from Amazon; requested a replacement directly, great service as you say, it didn't matter where I'd bought it originally.
But OpenPGP applet on Yubikeys cannot use ECC keys (no generation, no import). PIV applet can use ECC keys (but that's not covered in the attached article).
I broke my head recently trying to get this to work recently. The error was in 2 different gpg binaries that ubuntu ships with. Using gpg2 instead of gpg gets it working.
I have this exact setup working with a Yubikey and was a very happy user until I upgraded my mac to HighSierra, it would appear with the new native PIV integration with OSX that the yubikey is hogged by the OS and gpg can't get access to read it as a smart card. Every attempt to read it is greeted with
```
gpg: selecting openpgp failed: Operation not supported by device
gpg: OpenPGP card not available: Operation not supported by device
```
and the only solution I found was to remove OSX and replace it with linux which is now working again.
I haven't updated to High Sierra, but this would be very worrying. Can other people confirm whether or not a Yubikey is working for gpg on High Sierra?
A few weeks ago I found out about Bloomberg BUnit 4[0] (I was looking at their keyboards and got distracted).
I think we need something similar for consumers (as in, I don't want to end up spending 24k for a terminal just for a BUnit).
Basically it's a device that has a light sensor, a fingerprint reader and a code generator - all used to authenticate the user to Bloomberg services.
The closest I've gotten is using something like Trezor[1] or Ledger S Nano[2] (no fingerprint reader/light sensor - but it's protected via a passcode).
It's just one more level of protection on top of a hardware key (username + password + hardware key (protected by a password))
If someone can confirm that non-RSA (ECC, any curve) keys work with this or any guide, I'd appreciate hearing it. As far as I can tell, ECC silently and inexplicably fails at the ssh step. RSA seems to work fine.
This is Ubuntu 16.04, which comes with GnuPG 2.1.11.
No. You need a token running an OpenPGP Card 3.0+ applet for ECC. The Yubikey, while capable of doing ECC in other applets (like the PIV applet) only implements OpenPGP Card 2.1 (maybe 2.2?).
Some gnuk tokens, such as the Nitrokey Start support Curve25519, also for SSH authentication (I use this). Of course, gnuk tokens have a different set of trade-offs:
- In contrast to Yubikeys, the firmware is open source and can be verified.
- It uses a curve that is considered safe [1]. Some security experts don't trust the NIST curves.
- In contrast to the Yubikey, it does not use tamper-resistant storage, but just a regular microcontroller. AFAIK it does store the keys encrypted though.
- There is no physical confirmation for key use, only PIN confirmation (with a maximum number of tries).
However, gnuk keys are very affordable. E.g. I purchased my Nitrokeys for 29 Euro each.
A completely different approach is to use your phone (and its secure element) as a crypto token. E.g. using Krypton [2]. Of course, this is only viable if you trust your phone manufacturer and operating system.
(BTW re "AFAIK it does store the keys encrypted though," I'd be cautious about relying on that encryption. The keyspace for PINs is tiny and trivially brute-forceable. And if you choose to use a strong passphrase for your Gnuk token that is capable of resisting brute force, you're giving up one of the main usability benefits of committing a secret to a hardware token. I know they're working on something called KDF-DO that might offload key stretching to the host, but it's still going to be the case that PINs will be brute-forceable.)
Confirmed that 2.2.5 on Ubuntu 16.04 works with NIST P-256 for SSH authentication.
For future reference, installing GnuPG 2.2.5 turned out to be easier than I expected. I visited http://http.us.debian.org/debian/pool/main/g/gnupg2/, downloaded the .deb I wanted, tried installing with dpkg -i, and then downloaded further dependencies until it worked.
Last time I tried, I built GnuPG from source, which ended up with something that mostly worked, but it failed my personal sysadmin test of being able to remember how I did it in case I needed to build a new machine with the same characteristics.
Your answer makes sense, but I believe I do have a 3.0-compliant token. It's Gnuk tip of tree running on some STM32-based piece of dryer lint. According to Gnuk's README, it does support OpenPGP Card 3.0 (though the documentation is inconsistent about that). So I'm beginning to suspect it's the version of GnuPG that I have, but I don't think it's that out of date.
As for the PIV portion: Unfortunately, PIV will not work either. Right now, OpenSSH’s ssh-agent doesn’t have the ability to handle EDSA keys when using PKCS#11 (which is how the agent communicates with the “card”.
Has anyone used Yubikeys in conjunction with Ansible for deploying and maintaining cloud-based server fleets? I'd love some tips on handling the authentication; we'e had a brief foray into the matter, but never found a wholly ideal solution.
Could someone point a broader, general introduction to this topic? I often would like to adopt this technologies, but i always get stuck because I do not feel confident in adopting technologies that I do not fully understand.
As an awesome alternative you can use a Trezor (or KeepKey) with https://github.com/romanz/trezor-agent for GPG and SSH. Unlike the YubiKey, with the Trezor you have have to enter a scrambled numeric PIN to use it.
The last time I tried to set up my YubiKey Nano for SmartCard access the indicator light flashed incessantly. There is no option to turn it off and it is very distracting.
Has anyone else had this experience? Is it possible to turn the flashing off?
Almost anything that can run NeuG can also run Gnuk. You're not going to get tamper-resistant hardware -- unfortunately it's not possible today to buy truly open hardware with a tamper-resistant design -- but you'll get something that most people consider open.
Someone is going to reply to this and note sagely that all commercial hardware is proprietary. I don't interpret craftyguy's question as a rhetorical statement that we're all doomed.
many, however, effectively all of the smartcard hardware implementations are proprietary. The most open one I can think of is the OpenPGP card which is PC/SC standard compatible. It's sold by Free Software Foundation Europe and is colloquially known as the "foundation" card. However, while the applet source that runs on the Java card is available, I don't know about the firmware or runtime libreness.
It's be really great to have an auditable open source processor/soc design with PC/SC compatible interface and secure enclave implemented in an ISO standard smartcard form factor. Alas, to my knowledge nothing like that exists.
Yubikey designs used to be a lot more open than they are currently (you used to be able to run your own applets, IIRC - with some security compromises, of course). That said, I would still personally use them for non-critical things - it's a really handy form factor.
Can someone ELI5 why Yubikeys are better for 2FA than using, say, 1Password, which simplifies the process with cmd + \ and automatically pasting the 2F code? (Even better than Google Authenticator; no need to reach for anything.)
Using 1Password to store your 2fA seed makes it single factor because your password and second factor are stored in the same place. This is not a good idea.
Yubikeys in U2F mode are better than any OTP because they protect you against phishing attacks. 1Password auto-filling arguably has this property too, but you should disable that sort of password manager behavior:
Yubikeys in U2F mode are better than any OTP because they protect you against phishing attacks. 1Password auto-filling arguably has this property too,
Not really. The TOTP RFC recommends accepting TOTP tokens from before and after the current time step to make TOTP work with clock drift. Since most implementations use time steps of 30 seconds an allow TOTP codes of at least one past and one future time step, the window in which an TOTP code can be used is typically 90 seconds.
Consequently, TOTP only works against 'offline phishing' where a phisher collects data first and tries to take over the accounts later. For any kind of immediate phising, there is typically no problem to forward re-use the token, even with a small delay.
As you say, U2F protects against this, by using challenge-reponse and using the origin selecting the key handle.
I don't understand the start-off of "not really". Is that in reference to the first sentence or the 2nd? I think the "1Password-autofill" protects you against phishing because if you go to a legit site, the domain will match and 1Password will autofill. If you go to a phishing site that just looks right (Unicode domain, whatever), but doesn't match exactly then the auto-fill won't happen and you'll be tipped off.
> Using 1Password to store your 2fA seed makes it single factor
Thanks. I certainly understand that but the convenience trumps the risk imo. Further, I don't want to reach for and insert a USB drive every time I want to log in somewhere. And what if there's no available USB port?
I think it's better than having to deal with checking one's email or checking one's phone for a SMS and then having to manually copy the code into a form and submitting it.
The only thing that would be more convenient would be if the browser authenticated itself using a client side TLS certificate as one factor in the authentication process.
http://www.engineerbetter.com/blog/yubikey-all-the-things/
http://www.engineerbetter.com/blog/yubikey-ssh/
http://www.engineerbetter.com/blog/yubikey-static-secret/
http://www.engineerbetter.com/blog/yubikey-2fa/