Hacker News new | past | comments | ask | show | jobs | submit login
Yubikey guide for Git Signing, SSH Auth, U2F 2FA, and 1Password (2017) (engineerbetter.com)
155 points by EngineerBetter on April 30, 2019 | hide | past | favorite | 47 comments

(Title needs the year since the article is from 2017.)

For keeping SSH keys, the PIV module seems a bit simpler than GPG. I just went through the process myself.[1]

They should also mention FIDO U2F, which already works well with Google, AWS and Github among others. Implementing it for your own site also seems doable.

1: https://blog.snapdragon.cc/2019/04/27/using-a-yubikey-to-sec...

Very doable. I have FIDO U2F set up on my personal site and wrote a barebones example at https://jonathanstreet.com/blog/flask-second-factor-authenti...

I've thought about adding support for remembering devices but using the token is so easy it's just not a priority.

Agreed - in particular because PIV doesn’t prevent other apps subsequently using the device as gpg-agent does (necessitating unplugging and replacing it in the USB port).

On the flip side, with PIV there’s no way I’ve seen to have it allow access for a short period of time (eg the way gpg can cache the pin for a set number of seconds) instead of per request which can get a bit annoying if you are invoking ssh repeatedly (which I seem to do a fair bit).

Would also reference the excellent yubioath tool for adding TOTP passwords on sites which don’t support FIDO/U2F - it’s very very easy to use and if you have an Android phone and an NFC enabled yubikey you can use there too.


You can configure "--touch-policy=cached" when importing/generating a private key using the cli PIV management utility which will cache touches for 10 seconds Not sure why it's not exposed in the GUI though


>Agreed - in particular because PIV doesn’t prevent other apps subsequently using the device as gpg-agent does (necessitating unplugging and replacing it in the USB port).

I believe this is no longer the case? At least with current GPGTools on macOS, I leave a Yubikey Nano in one of my USB ports and use it for both GPG and U2F without issue.

>For keeping SSH keys, the PIV module seems a bit simpler than GPG.

If you're only using it for SSH, sure. If you also want commit signing, though, you'll need to set up GPG anyway.

Apologies - I updated the post today to include the commit signing, and didn't think about the date of the parent post.

I wish Yubikeys supported hardware AES encryption on the device, and a hardware entropy source (vibration, rf, probably couldn't fit atomic-decay-mesurement in a usb key, but something).

My personal tinfoil headwear has me believing that AES on any of the Big-2 CPU's is compromised, probably via key logging deep in the bowels of the die. And the RNG could have a similar backdoor.

> hardware AES encryption on the device

> AES on any of the Big-2 CPU's is compromised

In that case, which CPU could the Yubikey use?

> In that case, which CPU could the Yubikey use?

Dedicated AES engines exist. For example, the 3DS shipped with a AES engine inside its SoC, exposed as memory-mapped I/O.

FPGA or stock embedded CPU. I didn't mean literally any Big-2 CPU, I was thinking of desktop CPU's when I wrote that. I doubt the 8051's that you can buy by the spindle from electronics suppliers are backdoored, though its technically possible.

8051s also seem pretty under-powered for a task like that.

One thing with encryption on a USB-connected security dongle is that your scp / rsync / git pull invocation is going to go through it, and through its crypto engine. To make it not painfully slow, the crypto engine has to be pretty fast. It's likely not very cheap, either using a (fast) general purpose CPU core, or using custom / specialized circuitry.

Paying extra for high security at high speed may make complete sense in some cases. For a cheap mass-market product, it's less likely.

I've got two Yubikeys already (a Neo, and an older barebones Yubikey that I got as a gift for getting an Ars Technica subscription), but so far Gmail is the only account of mine that is protected by it.

One repeated problem I've run into so far is that Firefox can read the Yubikey when it's inserted but it can't add the Yubikey as a new device yet. I have to pull up Chrome/Chromium to do so. After my most recent laptop reformat I vowed never to install Chromium again, even temporarily, so, out of luck until Mozilla gets that fixed, I suppose.

If I understand correctly the problem you're seeing it's not a Mozilla bug

Although Google's site says "Your current browser doesn't support adding security keys" what they mean is "We don't care about any browsers except Chrome, it works in Chrome, just get Chrome". They don't implement the actual standard, even though they helped write it, because after all it works in Chrome™ as it is.

On sites that are built by somebody who actually cares about more than one browser, Firefox works just fine.

I wouldn't doubt that, although I ran into the same problem trying to register my Yubikey on GitHub as well. Could well be another "Built to Chrome spec, not the standard spec," I suppose.

Ah, for sites using U2F rather than WebAuthn you may (depending on Firefox version) need to explicitly tell Firefox to emulate the old U2F APIs.



My GitHub has two Security Keys registered via Firefox this way.

This is why you don’t do feature detection with the user agent header, but someone needs to tell that to the 800 lb gorilla. In this case though I’m not going to be too harsh because Mozilla wasn’t exactly tripping over themselves to implement U2F support - I think it took them 2-3 years, and I still can’t use a key with any of my IOS browsers (which I think are all just window dressing for apple’s html widget, so blame that on Apple).

Web site support that uses the feature on any browser has been slow also. Robinhood is the only financial app that I’ve found that even supports TOTP. My E-trade account still requires a hardware token with a little lcd screen on it - paging Captain Marvel.

Apple: Please support U2F, because "Privacy is a basic human right" [per your EULA], which requires security.

Shameless plug for a library that I wrote (still developing) for storing AWS API keys on a Yubikey (and signing API requests from the Yubikey): https://github.com/pyauth/exile

Has anyone actually seen personal SSH or Git signing keys get stolen and used in attacks (not counting servers sitting on the internet with ssh open) ? It seems like the only really useful purpose for these tokens is as an MFA token, because passwords just suck. At the same time, it seems like long random bits that can't be remembered by humans just aren't so vulnerable that we need to carry around something to unlock them.

Maybe the issue is just that it's so easy to attack password-protected systems that nobody even needs to attack keys.

I personally don't see the point in them at all, in implementation and reality you get basically zero use out of the things.

Services that support them either have them locked down so hard that if you lose a single Yubikey (there's often no backup second key option), you're very screwed. Others go the other option, and have too easy to reset systems, SMS fallbacks, or other total bypasses of the security tokens.

For SSH and GPG, authentication keys are generally the least of your concern. The content you're controlling are much more valuable than the authentication itself. Can an attacker just wait until you SSH somewhere, and leverage that access? Can they wait until you'd press the button for another benign purpose and use that authentication in a malicious way? The answer is almost always yes, which reduces the value of these sort of devices substantially. They don't protect against local compromise, in which case a keyfile sitting on your local host is just as secure and a lot more convenient.

Well their main use is to mitigate remote compromise. But I suppose if for some reason someone compromises a private key remotely (???), they don't have your physical 2nd key to complete auth. Or if you want encryption at rest with something stronger than a passphrase. For weird cases like "disk backup was compromised" it also helps, because most people don't encrypt backups at the client. But in general, actual protection seems vanishingly small past remote attacks.

So I think in general private keys aren't improved with a token, since a compromised private key is supposed to be a local compromise.

I don't really see a situation in which someone has local file read access on your machine, but doesn't otherwise have you completely owned.

A regular keylogger won't no longer work with a hardware token for example. Yes, having your PC compromised is bad but it would be even worse if the keys can be stolen and used elsewhere, it just rises the bar significantly for getting persistent access (re-establishment without the token is really hard) in my opinion.

I think they can be pretty beneficial in corporate environments where you can exert some control over the IDP and turning it on/off isn't super difficult (like visiting a physical help desk)

In addition, these places tend to have less technical users and "plug it in and press during login" isn't terribly difficult

I genuinely don't understand downvoting a series of very realistic comments about what using a Yubikey is actually achieving in these situations.

I agree, I bought a yubi key ages ago and have tried to set it up for ssh, windows auth and various online services but I find it either just doesnt work, or works poorly enough that I don't use it and instead rely on classic TOTP instead.

Usually these are configured to be the private key, not unlock the one on your computer. This prevents your key being hijacked (every signing operation requires a physical button press on the key) and prevents its theft.

If an attacker can exfiltrate your private key they can probably keylog your passphrase & your VPN details

PIV/GPG smartcard solves he former and 2FA solves the latter so something like a yubikey/nitrokey gives you both in one device

Anecdotally I do have a friend who had his private key & passwords pilfered which was noticed when someone tried logging in from some other country.

So, taking "personal" to mean specifically that they belong to an individual as opposed to a service account, yes, that definitely has happened in real security incidents with big consequences.

There's a 2008 Fedora incident of this sort, a Fedora Administrator's private key was "stolen" by bad guys and used to upload replacement packages which is well documented e.g. https://lwn.net/Articles/326170/.

I think we should assume that this has also happened plenty of times to organisations which have a default posture of not telling you about incidents at all unless required by law.

I like the added security of yubikeys, I use it for Google account and Facebook. Sadly it won't easily work everywhere, I seem to always have issues with my smartphone (missing adapter or rfid not working well), but my biggest pain is it doesn't work on PS4, my youtube account always gets unlinked randomly, than I need to go my computer, disable 2FA, sign-in on the ps4, and reenable 2FA.

I like the idea of SSH'ing with it, ill give that a shot.

It pokes a hole in your security but you could consider creating App Passwords for devices like the PS4 which do not support 2FA.


Yubikey 5 supports NFC for mobile, might work for your use case (smartphone challenges).

Indeed, though for SSH only on Android, not iOS, and only with GPG keys not PIV. ConnectBot and OpenKeychain are the apps you need to do this.

Also on Android (but again not on iOS), Chrome (but sadly not Firefox as far as I know yet) can use the google authenticator app (again sadly I think no alternatives to this yet) to speak FIDO with an NFC yubikey.

Storing your 1Password Master Password on a yubikey seems like a really bad idea for most threat models. This means that anybody in physical possession of the Yubikey can immediately and permanently steal your master password. Additionally, for shared computers, anyone who can run code on that system can log static creds, the same as if the user typed it.

You can store your 1Password master password (or any other static password) on your yubikey with a few of the last characters missing. You'll plug the yubikey in, press the button and manually type the missing characters to complete the password. This way if you lose it, however finds it has an incomplete password and no idea where it belongs to.

They're not storing the Master Password on the yubikey, they're storing the secret key, which are two separate things both required to log onto 1password, but the secret key is completely randomly generated.

Agreed! I don't use that feature at all for the same reason. I don't have my key with me at all times.

I've been using a Trezor crypto wallet for most of these things; it has password manager features but I haven't switched from LastPass for that yet.

I've even enabled U2F 2FA on my work desktop for log in, and use it as 1FA to unlock the screenlock, and it automatically locks when I unplug it. Very slick. You could do similar with YubiKey.

Does anyone use a Yubikey for personal rather than business/employment situations? Would a Yubikey ring make any sense for personal use (for example, you have Yubikey ring that connects via NFC with your device (phone, computer) and is require for auth'ing financial transactions?

I use a Feitian epass for my personal accounts (it seems like yubikeys are USB or NFC whereas I wanted a single key that would do both). It fits on my keyring (smaller than my house key) and claims to be waterproof. I wish I could use something like that for banking - it's much more convenient than the little card readers some banks use, and frankly I have more faith in its security. A ring form factor would be nice, but I don't think NFC on PCs is ubiquitous enough yet.

That is sort of the idea. It's a relatively cheap authenticator that can be bought to provide 2FA for added security for your services. You can integrate it with Gmail, Mac Logins, etc.

Yes, I'm interested in general adoption and whether general populous would adopt such a 2nd-auth if presented as a fashion item (i.e. make the authenticator more accessible).

In the UK Barclays and NatWest (maybe others) offer a card reader for 2FA for banking transactions, I assume based on something like HOTP.

It's worth pointing out that AWS does now support U2F, which isn't reflected in the posts.

I had this set for my old AWS work account, but unlike a good WebAuthn implementation I'm pretty sure AWS only allowed me to a set a single key.

I tolerated that because a work account administrator can let me back in if I lose the key, but this is very much a second class implementation and I think AWS ought to do better.

It's true. You can only set one 2FA factor on an IAM account. As a work around, I ended up making myself two IAM accounts: one tied to primary Yubikey and another to my backup. Certainly not ideal.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact