Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Hardware Touch, Stronger SSH

ubicloud.com

Post reply on HN
Print view View original

31–40 of 53 posts

Re: Hardware Touch, Stronger SSH

#31

Post by the8472 »

gruez wrote: post #28
machinationu wrote: post #14

Earlier quoted context omitted.

while you are right, security is generally not cheap. you can get that $5 china fido key, but are you sure it's you who owns it? I was recently looking for a security key, and eventually I did pay the yubico tax, because saving $20 by getting another one seemed unwise given the stakes.

>you can get that $5 china fido key, but are you sure it's you who owns it? Seems like a moot point because it'd be very difficult for a rogue fido key to exfiltrate data. I'd be far more concerned about random chinese IOT gadgets, which most people don't have a problem with.

Couldn't they ship pre-compromised? Storing the RNG seed and private key at the factory.

Re: Hardware Touch, Stronger SSH

#32

Post by layer8 »

PunchyHamster wrote: post #19
talkingtab wrote: post #12

In my opinion only, Yubico has done no favors to the Fido by their marketing. A result of trying to make Yubikey synonymous with Fido, it has become unclear what Fido does. And as a result of how they market their keys, decisions Fido keys are presented with a cost of $20 - $60. Why $60, for a simple Fido key? Because for $60 you get not only Fido, but Flippo, Froggo, x.6s8o and more-o. The result is that most people…

You're paying for brand and the fact they make key exfiltration very hard. Getting the key out of rpi4 will be trivally easy if someone stoles it, not so much for hardware key. I am surprised that competition didn't kept them in check, we're using them for more than a decade and the price just keeps slowly creeping in.

Run-off-the-mill smart cards have had non-extractable keys for decades. They only cost cents in manufacturing.

Re: Hardware Touch, Stronger SSH

#33

Post by solatic »

connicpu wrote: post #22
solatic wrote: post #11

This is how you handle it as an individual developer, but in a corporate environment things get real difficult, real fast. You need to set up your VMs and Git host to only trust certificates signed by an SSH certificate authority, and you need to work with users to submit the public key from the hardware-backed key to IT (controlling the CA) to get the public key signed and a certificate issued. Establishing trust wh…

I can't speak to actually setting it up, but where I work we have an IT-provided yubikey ssh-agent that handles getting all that stuff set up, and we just paste the public key from our individual yubikeys into our authorized ssh keys with our on-prem-hosted bitbucket server. However almost everyone I know quickly gets sick of touching the yubikey for every git remote operation and just generates their own local SSH k…

> almost everyone I know quickly gets sick of touching the yubikey for every git remote operation and just generates their own local SSH key to use for git since doing so is not forbidden

Yes, that's the exact problem at hand. If you generate your own local SSH key, the private key sits on the disk, and it can be stolen by malware (see article).

I'm asking how people set up the controls such that only hardware-based keys are signed by the CA.

Re: Hardware Touch, Stronger SSH

#34

Post by solatic »

DetectDefect wrote: post #23
solatic wrote: post #11

This is how you handle it as an individual developer, but in a corporate environment things get real difficult, real fast. You need to set up your VMs and Git host to only trust certificates signed by an SSH certificate authority, and you need to work with users to submit the public key from the hardware-backed key to IT (controlling the CA) to get the public key signed and a certificate issued. Establishing trust wh…

If you aready have an SSH CA, why not just issue ephemeral certs lasting for several seconds or minutes? What risk would be addressed by adding hardware keys into the mix?

How do you prevent malware running on the pwned laptop from asking for an ephemeral cert to be issued? How do you know a human being is in the loop? Usually ephemeral sessions are up to 15 minutes (also to deal with misaligned clocks and unhappy users) - plenty of time for malware to ship the cert back to a command-and-control server.

This is the key advantage of hardware keys, the fact that the physical press is required prevents the keys from being exfiltrated from the machine by malware.

Re: Hardware Touch, Stronger SSH

#35

Post by ComputerGuru »

the8472 wrote: post #31
gruez wrote: post #28

Earlier quoted context omitted.

>you can get that $5 china fido key, but are you sure it's you who owns it? Seems like a moot point because it'd be very difficult for a rogue fido key to exfiltrate data. I'd be far more concerned about random chinese IOT gadgets, which most people don't have a problem with.

Couldn't they ship pre-compromised? Storing the RNG seed and private key at the factory.

Devil’s advocate: How do they map that data to a user when you are buying through a maze of resellers?

Re: Hardware Touch, Stronger SSH

#36

Post by ComputerGuru »

simon04 wrote: post #7

Using a Token2 based id_ed25519_sk_rk key, I found very helpful to configure a different `pushurl` in `.git/config`. This allows to pull via HTTPS w/o a hardware touch. [remote "origin"] url = https://github.com/freeCodeCamp/devdocs.git pushurl = git@github.com:freeCodeCamp/devdocs.git

GitHub dropped http authentication so this only works for public repos (not that the UX or security of http auth for git is nice).

Can git be configured to use different keys for push and pull? (You can obviously use different upstreams, but thats not as elegant.) Most git servers let you specify read vs read-write privileges (aka “deployment keys”) so you could use one key to pull updates that doesn’t need touch and another key to push (which does).

Re: Hardware Touch, Stronger SSH

#37

Post by [deleted] »

connicpu wrote: post #22
solatic wrote: post #11

This is how you handle it as an individual developer, but in a corporate environment things get real difficult, real fast. You need to set up your VMs and Git host to only trust certificates signed by an SSH certificate authority, and you need to work with users to submit the public key from the hardware-backed key to IT (controlling the CA) to get the public key signed and a certificate issued. Establishing trust wh…

I can't speak to actually setting it up, but where I work we have an IT-provided yubikey ssh-agent that handles getting all that stuff set up, and we just paste the public key from our individual yubikeys into our authorized ssh keys with our on-prem-hosted bitbucket server. However almost everyone I know quickly gets sick of touching the yubikey for every git remote operation and just generates their own local SSH k…

[deleted]

Re: Hardware Touch, Stronger SSH

#38

Post by petee »

gruez wrote: post #28
machinationu wrote: post #14

Earlier quoted context omitted.

while you are right, security is generally not cheap. you can get that $5 china fido key, but are you sure it's you who owns it? I was recently looking for a security key, and eventually I did pay the yubico tax, because saving $20 by getting another one seemed unwise given the stakes.

>you can get that $5 china fido key, but are you sure it's you who owns it? Seems like a moot point because it'd be very difficult for a rogue fido key to exfiltrate data. I'd be far more concerned about random chinese IOT gadgets, which most people don't have a problem with.

One issue i see is that it's a sealed package; it wouldn't be immediately apparent if someone added extra hardware/functionality.

More likely though I'd expect you'd just get some form of a clone device

Re: Hardware Touch, Stronger SSH

#39

Post by ComputerGuru »

connicpu wrote: post #22
solatic wrote: post #11

This is how you handle it as an individual developer, but in a corporate environment things get real difficult, real fast. You need to set up your VMs and Git host to only trust certificates signed by an SSH certificate authority, and you need to work with users to submit the public key from the hardware-backed key to IT (controlling the CA) to get the public key signed and a certificate issued. Establishing trust wh…

I can't speak to actually setting it up, but where I work we have an IT-provided yubikey ssh-agent that handles getting all that stuff set up, and we just paste the public key from our individual yubikeys into our authorized ssh keys with our on-prem-hosted bitbucket server. However almost everyone I know quickly gets sick of touching the yubikey for every git remote operation and just generates their own local SSH k…

The obvious solution is an ssh-agent integration that caches the touch-derived key for up to N hours or until the workstation is locked (as a proxy for user-is-away event), AND integrates with secure desktop (à la UAC) to securely show a software-only confirmation prompt/dialog for subsequent pushes within the timeout window.

(Tbh, a secure-desktop-integrated confirmation dialog would solve most issues that needed a hardware key to begin with.)

Re: Hardware Touch, Stronger SSH

#40

Post by lmz »

solatic wrote: post #34
DetectDefect wrote: post #23

Earlier quoted context omitted.

If you aready have an SSH CA, why not just issue ephemeral certs lasting for several seconds or minutes? What risk would be addressed by adding hardware keys into the mix?

How do you prevent malware running on the pwned laptop from asking for an ephemeral cert to be issued? How do you know a human being is in the loop? Usually ephemeral sessions are up to 15 minutes (also to deal with misaligned clocks and unhappy users) - plenty of time for malware to ship the cert back to a command-and-control server. This is the key advantage of hardware keys, the fact that the physical press is req…

> This is the key advantage of hardware keys, the fact that the physical press is required prevents the keys from being exfiltrated from the machine by malware.

Secure elements prevent exfiltration. Touch requirements prevent on-device reuse by local malware.

Post reply on HN