Get the top HN stories in your inbox every day.
mjg59
smoothgrammer
Make sure you sign the information that indicates the requestor.
LoganDark
I've always been afraid to invest in something like a yubikey or even to use the TPM on any devices I own. I don't ever want to depend on "something I have" that can't be backed up or recovered in any way.
As an example, when I started using a password manager last year, I also made sure to start hosting the (encrypted) passwords database publicly (on a web server) so that if I ever lose it for any reason (SSD fails, etc) I'll be able to download it back onto a computer and unlock it with my master password.
If I ever lose my passwords database I'll also lose access to every internet account I've ever made. It would be far too risky to make it rely on any physical possession of mine.
Some people (most people??) would feel safe knowing that it's impossible for anyone to get into their accounts without their yubikey, but I'd just always be afraid of losing the yubikey.
foobiekr
I used to be very pro yubikey for a long time but have mostly concluded it doesn't really solve any of the problems people think it solves. It basically just provides a (1) a means to prove that you have access to a key, which isn't actually yubikey dependent, and (2) a way to demonstrate that said key is bound to a hardware device that makes it hard to steal/exfiltrate.
People are incredibly laissez faire about their yubikeys - leaving them plugged in, leaving them on their keys, etc. They are an obvious DOS vulnerability.
Another basic issue that key theft is actually mostly not a real attack that matters for most people.
Spearphishing and faked sites are handled by any password manager worth using. If your threat is protection from key loggers, either don't use a wired keyboard or you are likely in a place where your local device is assumed to be already compromised (by the logger and probably a RAT) so now things like session cookies theft, TOCTOU swapping between authenticated operations, etc. are all in scope and the yubikey offers essentially nothing.
On top of that, most sites that "support FIDO", including google, will almost always be configured to fall back to other means.
It does allow one to make a clever device into a shibboleth, though.
Hamuko
What's wrong with having your Yubikeys on your keys?
foobiekr
Evil maid attacks for pin theft, stolen YubiKey and denial of service, etc. it depends on whether you’re one of the people who leaves their keys sitting on their desk.
konha
> People are incredibly laissez faire about their yubikeys - leaving them plugged in, leaving them on their keys, etc.
You can (should) protect your YubiKey with a pin. They will lock/reset after a couple of failed attempts.
> On top of that, most sites that "support FIDO", including google, will almost always be configured to fall back to other means.
Google accounts can be configured to require hardware tokens for 2FA without fallback to less secure methods. [0] Apple has a similar program. [1]
foobiekr
Yes, you can configure google that way. People mostly don’t, however.
Yes, you can (and should) configure a pin. Now you have a DOS problem.
trompetenaccoun
Fair enough but at that point, why not just use a software based PW manager?
kimburgess
There's a fairly excellent guide on creating a robust key system here: https://github.com/drduh/YubiKey-Guide. Primary and backup Yubikey for use, offline cert keys, and paper backups.
If you're wanting to protect things further you can also also split your backups via a secret sharing scheme (like http://point-at-infinity.org/ssss/) and distribute the fragments to people or places your at least partially trust.
RockRobotRock
yubikey support for GPG has always been meh for me. FIDO2 ssh keys seem really promising. GPG definitely still has its place though
kimburgess
Both are useful.
GPG is good for signing, particularly when that signature is written into some form of immutable history (e.g. git). That signing key can be revoked or time windowed to expire. There are mechanism for distributing that revocation and its validity at the time of signing can be verified at any point in the future.
SSH keys are excellent for authentication. They are simple to verify at the time of use, and can also be revoked or for a specific system or usage context. Using these short-term keys for potentially long-term proofs is going to lead to some avoidable pain IMO.
palata
Once setup, for me it's working like a charm. I use GPG for signing (git commits + java jars/aars/apks), it just works.
smaudet
I think the other (IMO completely valid) concern is that you don't know what the Yubikey does, really.
The protocols are open source, sure, but how sure are you there aren't back-doors in them? The firmware tends to be closed source, I found https://onlykey.io/ but I can't speak to how truly open they are, having never used them (do they have e.g. specialized hardware/software requirements for building one?)
In the end, it strikes me as a security over-complication - 1. have key, 2. keep secret, 3. match key/password to situation (don't re-use keys). These dongles do 1. and 2. but miss the mark wildly on 3.
You can say all you like about "backups" but in the end I actually want some things to be less secure than others - if I have to throw out a device every time I forget a password, life becomes some combination of expensive, wasteful, un-tennable, unsafe. I should never need a password to get into my fridge, e.g., and after the key is in the ignition the car should just "work", no messing with SSO while changing lanes.
ikiris
This is a fundamental misunderstanding of how this security model works. You don't have to throw away anything, it just means you reinit that specific key.
Have multiple of them for redundancy, trust them all at your central auth point and this isn't an issue.
smaudet
I disagree > Have multiple of them for redundancy.
Yes so when I have 40 such tokens then I must worry about which ones to bring when for which devices, it's a usability nightmare.
I contend you should rarely if ever use one, they are (often) more trouble than they are worth. Or, you are reusing them everywhere, and so you violate the principle of re-use. Yeah, you can daisy chain things and the like, but now you are just making your life needlessly complicated and error prone.
muppetman
You don't put the password to your FRIDGE in a Yubikey tears
I mean I don't even understand the "throw out a device if you forget a password" bit. That's not how secure elements (Apple, Yubikey) work. They're just a "write private key once, never read again" device.
I would agree though, based on your comment, please don't waste your money on a Yubi or other similar "secure element" platform.
smaudet
To clarify, throw out as in, device (armed with a key/lock mechanism) becomes unusable (because said key is corrupted lost, lost amid mountain of other keys).
I am using password/key here somewhat interchangeably despite common (mis)understanding of what both words imply i.e. phrase versus some random(ish) bits, because the only distinction between the two is the algorithms used to compare (if you want to get pedantic pub/sub and splitting schemes are a bit more different, nevertheless they share the common theme of "secret used to protect something"). So no your YUBI has no password (that I know of) but it is effectively a password (by scanning it and reproducing it at a molecular level you could in fact reproduce it, it's as much a password with protection by obscurity in this sense as writing down a pass phrase backwards is, albeit one is much more difficult to reproduce than another).
user3939382
Best practice is to have multiple Yubikeys, at least 2-3. You could leave one with a trusted person or family member. The odds of losing all of them simultaneously are slim.
NoZebra120vClip
This is great, if you rarely add/update secrets and you also have easy, quick access to that offsite storage.
It's not so great if you're constantly tapping your friend because you need to swap Yubikeys again and you both just get sick of that rigmarole.
When setting up Yubikey, I discovered a tool, I think it's called "paperkey" and it lets you print out a GPG key after minting it. Have fun typing that back in! OCR ahoy!
It's lower-tech, but my solution is to always have a comprehensive catalog of plaintext backup secrets stored offsite. This won't rely on anything electronic and it's easy to use. You just have to make a good effort to guard it from prying eyes, at least any eyes that also know your username and password.
And likewise to some of the GPs, I'm skeptical of anything based on possession of an electronic thing that functions properly. The Yubikey is the best yet, because it's simple, purpose-built, and "virtually indestructible" as the marketing copy says. I would even love one of those RSA gadgets with a built-in display for purpose-built TOTP functionality. But paper's the best backup yet. Don't discount paper!
drowsspa
I've read this a lot, but honestly is this really the future of security? Keep a Yubikey in your wallet, another in a bank safe, bury another in the family's farm... It doesn't scale at all. And in the end, it's all social-dependent, because one can always cry out in a Hacker News post or in a viral Twitter thread and you'll get access to your account back. But if things happened the way security experts seem to want, losing your two Yubikeys means you should just start life from scratch.
I'd rather we find a way to actually involve real-world security instead of pretending the digital world doesn't depend on it.
tjoff
Oh, I need a new account. Hang on, can we book a new meeting in two weeks? I have to gather all my security keys first.
sneak
> I don't ever want to depend on "something I have" that can't be backed up or recovered in any way.
Just put one in each computer and one on your key ring and one in a safe. I have like 7. authorized_keys can have multiple lines in it.
LoganDark
> authorized_keys can have multiple lines in it.
I'm talking about more than just SSH keys—it just happens to include SSH keys as well. This isn't an opinion against Secretive specifically, for what it's worth, but rather against "something you have" in general, which includes TPMs (or Secure Enclaves, as it may be). It's my personal reason for not relying on something like that.
sneak
Almost everyone who supports U2F or WebAuthn also supports enrolling multiple keys.
trallnag
This sounds ridiculous.
sneak
I have a lot of computers because some of my clients are in regulated industries and if I ever get subpoenaed I can prune my company's proprietary non-customer-specific dotfiles and just hand over that laptop in full with 100% of that specific client's data on it and not compromise any personal/my-company's data or any other client data.
I don't like switching yubikeys and they make little tiny ones that live 24/7 in a USB-C port and they are cheap, so I literally just put one in each and every computer I type on. It's simple and easy.
aaomidi
Have more than one Yubikey, use paperbackup keys.
nathants
devices like trezor offer fido2 and backup/restore.
dang
Related:
Secretive: An app for storing and managing SSH keys in the Secure Enclave - https://news.ycombinator.com/item?id=28853329 - Oct 2021 (11 comments)
Secretive – macOS native app to store SSH keys in the Secure Enclave - https://news.ycombinator.com/item?id=23664129 - June 2020 (106 comments)
kylehotchkiss
I wish Apple would add more native support for this somehow. Until then, I’ve enjoyed using 1Pass for SSH key which continently allows me to share keys across machines, work confidently knowing my key isn’t accessible if a machine is lost, and asks me for Touch ID permission
mjg59
Apple actually made this much harder than it should be by special-casing P256 ECDSA in their build of libressl, which means trying to use it with PKCS#11 breaks: https://mjg59.dreamwidth.org/64968.html . The approach Secretive uses (which is what I ended up mimicking) is using the SSH agent protocol rather than PKCS#11, which lets you do the crypto in your own codebase instead.
VoxPelli
I was considering this but ultimately opted for 1Password’s SSH Agent instead and storing my SSH keys there and unlocking it with Touch ID: https://developer.1password.com/docs/ssh/agent/
Also use it to sign my git commits: https://developer.1password.com/docs/ssh/git-commit-signing
e1g
I have the same setup and can vouch that it works very well. My primary threat vector is data exfiltration by a compromised binary/node_module. A script reads everything in $HOME and sends it offsite. This is challenging to defend against, considering how many secrets want to live in plain text files (dot files, DB, AWS configs, backups, ssh keys, etc.), and file permissions do not help when the script runs with my user privileges.
buildbot
NB: If you use this, make sure to backup the key somehow. About a year ago I tested this with a few servers and lost all of the keys when my Mac had a kernel panic that wiped the state of the Secure Enclave! Updates can do this too!
runeks
The trick is to have multiple SSH keys -- spread out over several physical devices -- all of which are in your server's authorized_keys.
riobard
Correct me if wrong, but I thought that you cannot extract the private key from the Secure Enclave at all?
friendzis
This is true for any [citation needed] hardware security module. The interface allows to store/generate secrets and request cryptographic operations (encryption, signing, etc). Aside from physically tampering with the chip to access bits in raw silicon there is no way for the secret itself to leave the chip. Software security modules behave the same way, with the exception that one does have software access to the backing encrypted storage.
Too
Yubikeys can be backed up, using what they call export under wrap. It requires you initially created the key with exportable flag. The idea is you do this on first use to create an encrypted backup and then instantly remove the exportable flag from the key you carry around day to day.
As others already noted, having more than one key is a good idea anyway. If you are really serious, use ssh certificates so you don’t have to update every server with new keys. Just sign them with the root CA.
pocketarc
Yes, you can’t extract it, the Secure Enclave can just create a key and has it to sign stuff.
You can never actually grab it or access it for backing up, so it shouldn’t be your only way of accessing a server, there should be another authorised key that you do have access to.
olliej
It depends on the setup. You can generally only ask an hsm to perform a few specific operations “encrypt this data”, “sign this data”, etc and you’re restricted to the exact formats that it supports.
Because they are generally not very configurable (their design goal is to be secure and so the less complexity the better) it’s fairly common for them to just not directly support any specific cryptographic protocol.
Given that, what you can choose to do instead is have the hsm generate a key for you, and then you use that key to wrap your specific secret - say an ssh key - then you decrypt it when you need it which requires user authentication through the hsm - use the raw key and then clear it from memory.
But if the only record of the external key is wrapped by the hsm, if the hsm loses that decryption key then you’ve lost access to the ssh (or whatever) key as well.
fulafel
It's designed to make it hard, but it does crypto operations using the key so it's in there and possible to extract similarly as other tamper resistant chips have been successfully physically attacked.
adastra22
The whole point is that you literally can’t backup the key.
ikiris
No, this is what ssh certs are for.
You can use any key you want as long as you get a CA that everything trusts to sign it.
booi
hmm, where do you store the CA private key? We're just going around in circles
friendzis
> hmm, where do you store the CA private key?
On another device.
> We're just going around in circles
Depends on attack vector. Both solutions store private key in HSM and hence protect against "attacker gains access to local memory/storage". However, ssh certs allow key to be "regenerated". HSM'd keys are subject to "device got lost/destroyed" attack, HSM'd certs are subject to "CA got compromised". Pick your poison.
mbreese
The point isn’t how to secure the CA’s private key. The point is that this is a separate system that is probably easier to secure. Physically, it’s probably in a data center. If you want to, you could have the CA key loaded into memory at boot time with a removable USB drive.
That key should be easier to protect than a private key on an end user computer, Secure Enclave or not.
undefined
ikiris
in a safe at the bottom of the ocean? who cares, put an intermediate signer in a cloud somewhere that requires 2FA with multiple valid tokens, and everything is now much more secure and not tied to your specific key.
drdaeman
There is no export or import functionality with Secure Enclave. Unlike with Yubikeys or similar HSMs, you can't even migrate your pre-existing private key(s) into SE.
nixpulvis
What I kinda want is a way to use a detachable hardware key like a Yubikey as a primary factor for SSH and login authentication. I have multiple computers and I provision new OSes frequently and I always find it irritating depending on either network or flash drive synchronization for secret material when I could just be plugging in a smartcard device.
Anyone gone down this path?
ratorx
GPG keys are one option, but only recommended if you need compatibility. Having to deal with GPG + GPG agent is enough to make them a pain to use.
The modern way is SSH resident keys. However, this requires a “modern” SSH version (8.2), but does not add a dependency on GPG. Modern in this case, is a version from 2020.
zikduruqe
Of all the tech stacks that I have to deal with on a daily basis, I just don't get how GPG is hard. It is just like any other tool.
But, I just copy my ~/.gnupg directory to my new machine or to some backup server and all my gpg backed ssh keys/configs are portable. It's not terribly hard.
ratorx
IMO, GPG has a pretty terrible CLI. GPG agent config is complicated and is more of a pain to get working with forwarding etc. I don’t like the fact that GPG requires config at all. I also have no use for it, that I can’t solve with something nicer. I use age/sops for my encryption-related use cases. If I needed signing, I’d probably use minisign or signify. For authentication, Wireguard/SSH.
But for the SSH key use case, none of this matters. Unless you need compatibility with old SSH servers/clients, resident keys are substantially simpler, because they cut out 1 tool entirely and don’t require copying any directories to other machines.
nixpulvis
See my other comment for why I don't think SSH resident keys accomplish what I'm looking for. I'll have to experiment with using gpg-agent a bit, that sounds promising although potentially irritating to configure cross platform.
ratorx
You don’t need a file on the client for resident keys. You have to run a command to load them into the SSH agent, but you don’t need any information for that.
https://developers.yubico.com/SSH/Securing_SSH_with_FIDO2.ht...
mimsee
You can use the security-key variants of ssh keys. Those would be ecdsa-sk, ed25519-sk and others[0]. This does require a newer OpenSSH version to work. GitHub has added support for these keys back in 2021.
[0]: https://news.ycombinator.com/item?id=22324074
[1]: https://github.blog/2021-05-10-security-keys-supported-ssh-g...
MadQ
This is possible with PGP Keys stored on the Yubikey and used as the SSH keys. Check the Repo of drduh as a starting point
nixpulvis
Correct me if I'm wrong or missing something, but doesn't the use of SSH resident keys still require a file to be present on the client before it can authenticate? I'm prompted to use the SK to prove my 'presence' after the standard identity secret keyfile is checked.
To be clear, my goal is to simply plug in my SK to a fresh OS install and "magically" be able to SSH into my servers.
trevorthejag
Maybe not “magic” but you can get very close to that with “Discoverable Credentials” on a FIDO2 key.
The process for using a discoverable key on a new machine re-imports the relevant public key and private key handle to the new machine when you “ssh-keygen -K”. Its roughly equivalent to copying key material around with a flash drive, but without the need to remember two physical items.
acdha
That’s how it works for me. I generated a new key on the device, installed the public key where appropriate, and tap to authenticate.
UniqueUsername0
Look up ssh -sk keys. OpenSSH has been supporting FIDO2 secured keys for quite a while now. You're specifically looking for "resident" keys.
als0
YubiKey already supports those scenarios, I think.
obscurette
Looked at it at some point with hope that it'd provide easier user experience to use SSH with Yubikey PIV functionality on Mac. Unfortunately it doesn't support RSA keys we have to use for various reasons.
mjg59
It's not really so much that Secretive doesn't support RSA keys, it's that the SE doesn't
macrolime
How I'm setting up SSH access currently is to use two factor authentication where one of the factors is a device identifier, i.e. SSH key stored in TPM or with this on the Secure Enclave on a Mac, allowing only access from trusted devices. The second is a user identifier, stored in a yubikey.
In sshd_config, you can enable multifactor authentication with a comma separated list after AuthenticationMethods, for example publickey, publickey to require two keys.
https://manpages.debian.org/bullseye/openssh-server/sshd_con...
MaxMatti
Wouldn't that mean that I can login with any two keys? So instead of laptop+yubikey I could login with the keys from two laptops? Or from two yubikeys?
aprilnya
What if someone gets 2 of the yubikeys?
ahepp
Wow, this is really exciting! I have wished something like this existed, I'll have to try it out. I would love to use touchID to protect my ssh keys instead of a password!
dewey
If you are using 1Password it's also possible already: https://blog.1password.com/1password-ssh-agent/
VoxPelli
I opted for this instead when I decided to look this up, works really great!
nelox
This is excellent.
A different way of enhancing the security of a private key is to use a passphrase and store the passphrase in the macOS Keychain. Then, configure ssh-agent to always use the Keychain. When you login to your Mac user account, it will unlock it for use with ssh.
The encryption key needed to decrypt the Keychain is stored inside the Secure Enclave.
If someone manages obtain your private key, they would also need guess your passphrase or gain access to the Secure Enclave.
WhyNotHugo
Doesn't Secure Enclave offer a smartcard-like interface on macOS?
SSH already supports using hardware-backed keys via smartcard interfaces, so such an interface would allow it to work without any extra moving parts.
I keep seeing lots of new programs that are basically "Secure Enclave for X", where X already supports hardware-based keys via existing interfaces.
mjg59
Not directly - you can use CryptoTokenKit to bind SE keys into the keychain as if they were a smartcard, but there's no shipped tooling for that.
Get the top HN stories in your inbox every day.
Secretive has to function as both a key generation utility and an SSH agent because of a restriction in Apple's Secure Enclave functionality - only the app that generates a key is allowed to use it. There's actually a workaround for this, which is to use https://developer.apple.com/documentation/cryptotokenkit to expose keys to the user keychain, which then means the tool used for key generation doesn't have to be the same tool that allows applications to make use of that key. We're using this internally to generate keys that are then combined with user creds to receive x.509 and ssh certificates, and exposing the ssh certs to ssh using the SSH agent protocol. Our next step is to take that a step further and use https://developer.apple.com/documentation/devicecheck/access... to verify that the device asking for a cert is a device that we own (IT will be able to set one of those bits during device provisioning, and then we query that data during certificate issuance to show that the request comes from something we provisioned)