Hacker News Reader

Comment by upon_drumhead | Hacker News Reader

At this point, everyone needs to switch to https://github.com/maxgoedjen/secretive

>Because secrets in the Secure Enclave are not exportable, they are not able to be backed up, and you will not be able to transfer them to a new machine. If you get a new Mac, just create a new set of secrets specific to that Mac.

I consider that to be a deal-breaker. Hardware fails/lost/stolen, and I need to know that I have an offline backup somewhere if disaster strikes.

You could always register two keys, at least where that is supported, one for your Mac, another a hardware token that resides in a safe. Requires diligence, though, and is hard to verify that it’s been done correctly everywhere.

Using private keys the way they are supposed to be used is a deal-breaker? You're supposed to have (at least) one keypair per device, so if you lose the device, you can restrict access by revoking the keypair belonging to the lost one.

Are you currently sharing one keypair for all your devices?

It is about being prepared for disaster.

If I use ten services registered with my private key, and the single authenticated hardware device goes poof (dies/lost/stolen) -is there an out of band mechanism for me to regain access on a new device? Maybe for some, but possibly not all.

An offsite backup means that if everything goes down Monday, I can be back in business on Tuesday without fear.

You could replicate some of this assurance with redundant hardware devices, but that requires perfect diligence in ensuring you have multiple devices approved to each service. AWS only just recently allowed multiple hardware tokens.

Generate a separate SSH key which is only stored in your offsite backup (and then also encrypted with a password), and not on any of your physical machines.

I must be missing something. If this novel key only exists inside my backups, it is not registered with any external services, and it cannot be used in the event the primary key is lost.

For me to register the backup-only key with other services, it would have to live on my machine, and be simultaneously registered in addition to the primary key. I am not sure what I am gaining vs having a backup of the primary key other than increased operational burden.

You can keep just the public part of the backup key on your current device and always enroll the two keys at a time.

But yeah, if the main device is stolen, it can be a pain to go update all the services with the new device’s key.

I personally use the gpg app on my youbikey for this, and the secret key comes from a backup I install on a livecd.

Ah duh, keep the public part on the device.

However, that very quickly gets into the problem of untested backups. I am then relying completely upon a private key which has never been validated to work.

Note that this comes with a set of pretty important caveats, notably no way to backup keys. Which means you absolutely need to have some way to regain access to whatever you secured with this - either via a backup key, by having another person that can grant access or similar.

Regardless of how good that project might be: No, we don't.

Might be appropriate to store keys in Secure Enclave for some but a dedicated TPM (Yubikey/Nitrokey/Trezor/Ledger/etc) is often preferred. Some might want or need backups.

And even then, having multiple implementations widely used is preferred over having everyone relying on the same small group of volunteers or corporate working on any single one.

Would this be more secure than using GnuPG (https://incenp.org/notes/2015/gnupg-for-ssh-authentication.h...)?

That is really cool. Apple should add support to their ssh implementation to do something similar.

Superior to using ssh agent of software like bitwarden or keeper etc?

This great find!

Reply on news.ycombinator.com