Remix.run Logo
asveikau 18 hours ago

I've always felt that having your keys tied to specific hardware will just lock you out when the hardware breaks. Maybe I'm overstating the risk. It's a good idea to have multiple methods and test the backups.

jagged-chisel 18 hours ago | parent | next [-]

The general consensus has been that you create a key pair per client computer that you use. If one is stolen (say your laptop), you login from your desktop and revoke the stolen key. If the hard drive fails, you login from another client.

I don’t see much difference between that and storing the key on a TPM. If you have one key and you lose access to that key, then you lose access to the server.

Point: you need a backup key anyway.

jamiesonbecker 17 hours ago | parent [-]

One key per device is exactly what we recommend too. Private keys should always be protected as much as possible within that device and should never leave that device.

Just paste all of your devices' public keys into your authorized_keys file and leave a comment at the end for what device it's for. in Userify, it literally goes right into your nodes' authorized_keys file almost verbatim. (disclaimer: I work at https://Userify.com)

And then, if you leave your token or laptop at the airport or whatever, just remove that key right from your phone and it'll take effect in seconds across all the nodes/instances (if you're using Userify) or you can just write a quick for-inline-sed loop to remove it from your authorized keys everywhere.

SomeHacker44 18 hours ago | parent | prev | next [-]

Agree. This is why I do not use Passkeys, and I have 4 physical Yubikeys tied to every system I secure with them.

qurren 17 hours ago | parent | next [-]

I still don't understand what the hell passkeys are. Weren't passwords and {hardware keys | authenticator apps} enough?

I don't think average Joe is going to understand these passkeys either.

palata 16 hours ago | parent [-]

A passkey is just a thing that authenticates with FIDO2 (or is it WebAuthn?), I believe.

With a password, you open your password manager, copy the password in memory, paste it into the input field and trust that nobody could read it from your clipboard and that the program handling the password does it correctly. If your password leaks on the way, it's leaked.

With FIDO2, the server sends a challenge and asks your HSM (or TPM, not sure what the right word is) to sign it with your private key. So the server can verify that you own the private key, but if the challenge or the response leaks, it's just this one time. Next time it will be a new challenge.

Also for the average Joe, the result is that the "passkey" is the fingerprint or the face recognition and there is no password. It feels like they have only one password: the biometry/face recognition (or a master password, I guess?). So passkeys are superior to passwords in that sense.

Fun fact 1: some people hate passkeys because they don't want to be forced to rely on TooBigTech for them. Currently I use my Yubikeys as passkeys everywhere and it works well, so I do NOT depend on TooBigTech.

Fun fact 2: FIDO2 on current Yubikeys (and HSM in general, I think) tend to use classic cryptography which would be broken by quantum computers. A password used with symmetric encryption is not broken by quantum computers. So there may be a period of time where this becomes a tradeoff (you may have to decide whether the most likely attack is a quantum computer breaking your authentication or a malware stealing your password)?

Ferret7446 12 hours ago | parent | next [-]

> A passkey is just a thing that authenticates with FIDO2 (or is it WebAuthn?), I believe.

Not quite. First of all, passkey is not a standardized term. But usually it refers to a key that can be used for authentication on its own, not as a 2FA along with a password.

A FIDO2 key can be a passkey, or not, depending on the service or configuration.

FIDO2 and WebAuthn added some fields necessary to make this work "securely", e.g. asking the key to verify the user separately (e.g. a PIN, which serves as a second factor), or asking the key whether it is device bound or roaming, so individual sites/enterprises can enforce their security policies

qurren 16 hours ago | parent | prev [-]

> With a password, you open your password manager, copy the password in memory, paste it into the input field and trust that nobody could read it from your clipboard and that the program handling the password does it correctly. If your password leaks on the way, it's leaked.

I don't do that. My password manager simulates keystrokes 2 seconds after I hit the button. I switch to the other window and my password gets punched in without going through the clipboard. Specifically to avoid this attack.

> Currently I use my Yubikeys as passkeys

I have Yubikeys but for 2FA. So we're back to 1FA now but just "something you have" and no "something you know" ?

palata 16 hours ago | parent [-]

> I don't do that. My password manager simulates keystrokes 2 seconds after I hit the button.

So a malware on your computer can just listen to the keystrokes, or read on the screen? If the OS is compromised, they can extract the password. With a passkey they can't.

> So we're back to 1FA now but just "something you have" and no "something you know" ?

You can set up a PIN on your Yubikey, so that's "something you have" and "something you know", and you can request physical presence ("touching the yubikey") on top.

deepsun 18 hours ago | parent | prev | next [-]

Cloud-based passkeys are okayish (1pass, bitwarden), as they are available on multiple devices.

However not all devices play well with it, e.g. iOS and Android don't ask 1pass for the passkey. I also couldn't make it ask NFC for my hardware Yubikey with passkeys, but maybe I just did something wrong.

sitting33 17 hours ago | parent [-]

Passkeys are supposed to cover two authentication factors at once (having your device + biometrics). Because your yubikey doesn't implement biometrics, it's only a single factor, and thus cannot be used as a passkey.

deepsun 16 hours ago | parent | next [-]

Yubikey can be used as passkey atorage, I do it on Linux desktop/laptop with passkeys. It requires touching it (but no biometrics). I just couldn't make Android ask my hardware device, it wants to handle passkeys by itself.

It's false that passkeys cover biometrics. They cover password + OTP (aka 2FA aka MFA, although BestBuy requires OTP even after logging in with a passkey).

palata 16 hours ago | parent | prev [-]

Well a Yubikey can require a password/PIN. So having your device + knowing the password.

palata 16 hours ago | parent | prev [-]

I don't get this. Why don't you use your Yubikeys as passkeys then?

Ferret7446 12 hours ago | parent [-]

Likely because GP is misinformed about what passkeys are, which is understandable because they have not been marketed very clearly at all (though I do wish technically literate folks would actually do some research into "new" tech before parroting opinions based on their technopolitical alignment)

pseudohadamard an hour ago | parent | prev | next [-]

It's unlikely to be inside the TPM. The way pretty much all TPMs store data is to use a key inside the TPM to encrypt data stored outside the TPM, because the TPM is a repurposed smart card with barely any storage or capabilities outside of DRM. Bitlocker is an extreme example of this, but things like Fapi_CreateSeal()/Fapi_Unseal() also store the sealed item outside the TPM even though they appear to be using the TPM for storage. So what you do is the same as what Bitlocker does, use the TPM's storage root key (SRK) to seal some master key (in Bitlocker terms the VMK) and the master key seals the encryption key used, which is also sealed with some user-entered emergency-access password or whatever that still gives you access if the TPM dies.

OTOH for SSH use if you lose the key you just create a new one, it's not like you've lost the only copy of your Bitlocker key.

auraham 18 hours ago | parent | prev | next [-]

I have the same concern with all hardware used for storing keys and secrets for crytpo.

atoav 18 hours ago | parent | prev [-]

I mwan a key isn't that long. Convert it to a QR code, print it out and stick it somewhere safe.