5 ms·

I'm going to ask a naive but honest question: what is the security benefit of a piece of "key-hardware" over a passphrase protected key stored on a "normal" sto

by hnarn 5y ago

I'm going to ask a naive but honest question: what is the security benefit of a piece of "key-hardware" over a passphrase protected key stored on a "normal" storage device? I understand that for someone that moves between multiple physical machines it may be a benefit of convenience, but what threat vector does a physical key eliminate that exists for passphrased "normal" SSH keys?

krab 5y ago
Malware shouldn't be able to silently copy the key. Usually you have to touch the device to confirm usage. Even if the malware got your one time password when you thought you confirmed a legitimate operation, the attacker wouldn't get persistent access. Edit: Also, most people don't use them, so some attackers won't bother with more complex target.
- FranchuFranchu 5y ago
  The first difference can be negated by using an unplugged storage device to store the key. The second one is trickier since you need to do processing to prove that you have a private key, so you'd have to send the key to your own computer which breaks the whole point. You could use a separate "key" computer who owns the keys and that computer is the one that proves that it has the private key, but at that point you'd be better off using a normal security key since it's basically the same thing.
  - deleted 5y ago
    [deleted]
  - gabeio 5y ago
    Unless I am missing something, security keys never send the private key anywhere so the computer can not access it. Unlike an unplugged storage device which can be read by malware once plugged in, and need to be read into memory by the computer for use.
oprah 5y ago
One obvious thing would be keyloggers?
g_p 5y ago
Your software based key is exposed unencrypted to the host OS and any software running on it. It likely sits in memory unencrypted for some period of time. Malware that steals your key can "clone" it. A dedicated hardware device never exposes the key to the OS itself - if your host gets compromised, power it off, re-image or replace it, and your keys are still protected - malware on the host didn't steal the underlying key. It might have pre-signed some attestations or similar (hopefully your token requires hardware user input like pushing a button to use it), but it won't have had any access to your key, so can't "clone" it.
kissgyorgy 5y ago
You can't get the private bits out from the hardware, it always stays on the hardware, never leaves it. As for the simple storage device, you can just copy it to another one. Also as others mentioned, the private bits are not exposed to the operating system, so no process can access it.
Androider 5y ago
SSH secret key file exfiltration by running "npm install" or the like is a concern, and by using YubiKeys this type of attack is eliminated. You can also enforce usage of YubiKeys, but you can't really enforce every developer sets a passphrase on their locally generated SSH key file. And it's a convenient, and consistent way of authentication: Your work Google Workspace account uses and enforces a YubiKey, your AWS account login uses and enforces a YubiKey, and now your GitHub account also uses (but cannot not yet be made to enforce AFAIK) a YubiKey. It's less hassle than using one-time codes with fifty-seven different apps and cloud environments, so there's not much user push back.

by hnarn 5y ago

krab 5y ago

Malware shouldn't be able to silently copy the key. Usually you have to touch the device to confirm usage. Even if the malware got your one time password when you thought you confirmed a legitimate operation, the attacker wouldn't get persistent access. Edit: Also, most people don't use them, so some attackers won't bother with more complex target.

FranchuFranchu 5y ago
The first difference can be negated by using an unplugged storage device to store the key. The second one is trickier since you need to do processing to prove that you have a private key, so you'd have to send the key to your own computer which breaks the whole point. You could use a separate "key" computer who owns the keys and that computer is the one that proves that it has the private key, but at that point you'd be better off using a normal security key since it's basically the same thing.
- deleted 5y ago
  [deleted]
- gabeio 5y ago
  Unless I am missing something, security keys never send the private key anywhere so the computer can not access it. Unlike an unplugged storage device which can be read by malware once plugged in, and need to be read into memory by the computer for use.

oprah 5y ago

One obvious thing would be keyloggers?

g_p 5y ago

Your software based key is exposed unencrypted to the host OS and any software running on it. It likely sits in memory unencrypted for some period of time. Malware that steals your key can "clone" it. A dedicated hardware device never exposes the key to the OS itself - if your host gets compromised, power it off, re-image or replace it, and your keys are still protected - malware on the host didn't steal the underlying key. It might have pre-signed some attestations or similar (hopefully your token requires hardware user input like pushing a button to use it), but it won't have had any access to your key, so can't "clone" it.

kissgyorgy 5y ago

You can't get the private bits out from the hardware, it always stays on the hardware, never leaves it. As for the simple storage device, you can just copy it to another one. Also as others mentioned, the private bits are not exposed to the operating system, so no process can access it.

Androider 5y ago

SSH secret key file exfiltration by running "npm install" or the like is a concern, and by using YubiKeys this type of attack is eliminated. You can also enforce usage of YubiKeys, but you can't really enforce every developer sets a passphrase on their locally generated SSH key file. And it's a convenient, and consistent way of authentication: Your work Google Workspace account uses and enforces a YubiKey, your AWS account login uses and enforces a YubiKey, and now your GitHub account also uses (but cannot not yet be made to enforce AFAIK) a YubiKey. It's less hassle than using one-time codes with fifty-seven different apps and cloud environments, so there's not much user push back.