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

You don't want long-lived keys

argemma.com

Post reply on HN
Print view View original

41–50 of 65 posts

Re: You don't want long-lived keys

#41

Post by pyvpx »

lelanthran wrote: post #39
cyberax wrote: post #20

Earlier quoted context omitted.

This is completely solved by SSH certificates. You still have the same private key in the hardware, but instead of using the public key directly, you issue temporary (~1 hour) SSH key certificates. I even automated it using an SSH proxy. The target machines then just need to put the CA cert in the authorized_keys files.

> The target machines then just need to put the CA cert in the authorized_keys files. The word "just" is doing a lot of work there. You update authorized_keys every hour for your entire fleet?

Sounds like a job for dnssec and sshfp records

Ahh, now you have three problems…hrm

Re: You don't want long-lived keys

#42

Post by Flimm »

ferngodfather wrote: post #35
akerl_ wrote: post #34

Earlier quoted context omitted.

This sounds more like a reason to automate token management than an argument for long lived tokens.

But then you just move the security issue elsewhere with more to secure. Now we have to think about securing the automation system, too. This is the same argument I routinely have with client id/secret and username/password for SMTP. We're not really solving any major problem here, we're just pretending it's more secure because we're calling it a secret instead of a password.

Secrets tend to be randomly-generated tokens, chosen by the server, whereas passwords tend to be chosen by humans, easier to guess, and reused across different services and vendors.

Re: You don't want long-lived keys

#43

Post by winstonwinston »

lelanthran wrote: post #39
cyberax wrote: post #20

Earlier quoted context omitted.

This is completely solved by SSH certificates. You still have the same private key in the hardware, but instead of using the public key directly, you issue temporary (~1 hour) SSH key certificates. I even automated it using an SSH proxy. The target machines then just need to put the CA cert in the authorized_keys files.

> The target machines then just need to put the CA cert in the authorized_keys files. The word "just" is doing a lot of work there. You update authorized_keys every hour for your entire fleet?

No, the ssh CA model works like this: servers trust one CA, and the CA signs user keys. No more distributing individual public keys to every machine.

It is the user machine that needs new certificate signed by the CA once the short-lived one expires.

Re: You don't want long-lived keys

#44

Post by collabs »

Flimm wrote: post #42
ferngodfather wrote: post #35

Earlier quoted context omitted.

But then you just move the security issue elsewhere with more to secure. Now we have to think about securing the automation system, too. This is the same argument I routinely have with client id/secret and username/password for SMTP. We're not really solving any major problem here, we're just pretending it's more secure because we're calling it a secret instead of a password.

Secrets tend to be randomly-generated tokens, chosen by the server, whereas passwords tend to be chosen by humans, easier to guess, and reused across different services and vendors.

How does this apply to ssh public keys?

Re: You don't want long-lived keys

#45

Post by acdha »

jakub_g wrote: post #36

My favorite are the systems where you can only issue one token, so that you can't do a zero downtime rotation by creating new one, making it active in your system, and only then removing the old one. In some cases this makes rotation a big event to be avoided because costs are higher than gains.

I am still surprised that Keycloak makes this so hard. They finally added support for n=2 but it’s still walled off behind a “this is experimental, use at your own risk” warning, and it’s something that literally every OIDC client needs to do if you have any kind of compliance requirements.

Re: You don't want long-lived keys

#46

Post by traceroute66 »

Dragging-Syrup wrote: post #14
cyberax wrote: post #12

On the contrary. We want long-lived keys. As long as they are not symmetric! My private SSH key is rooted in hardware and can't even be extracted. This is awesome, I don't have to worry about it getting compromised. The same should apply to all other keys, including the dreaded "bearer tokens".

I’m sorry to be pedantic, that’s not exactly true. I agree in the sense that extracting hw based keys is next to impossible, but if your machine is compromised, there isn’t much stopping malware from using your hw based key (assuming 1. Left plugged in, 2. Unlocked with either ssh-agent or gpg-agent, and 3. You don’t have touch to auth turned on). Reduced risk? Absolutely. No risk? Absolutely not.

> there isn’t much stopping malware from using your hw based key

Except the three pretty major things that do stop malware that you mentioned ;)

Perhaps especially "3. You don’t have touch to auth turned on".

Re: You don't want long-lived keys

#47

Post by traceroute66 »

hsbauauvhabzb wrote: post #16
Dragging-Syrup wrote: post #14

Earlier quoted context omitted.

I’m sorry to be pedantic, that’s not exactly true. I agree in the sense that extracting hw based keys is next to impossible, but if your machine is compromised, there isn’t much stopping malware from using your hw based key (assuming 1. Left plugged in, 2. Unlocked with either ssh-agent or gpg-agent, and 3. You don’t have touch to auth turned on). Reduced risk? Absolutely. No risk? Absolutely not.

And if you want to be even more pedantic, shell access with a touch based key just means the attacker has to wait for you to auth, which makes touch based systems largely a waste of effort on the defenders part.

> shell access with a touch based key just means the attacker has to wait for you to auth

And if you want to be EVEN more pedantic, on most touch-based keys, you have to touch within 10–15 seconds otherwise it times out.

So it is not a waste of effort at all. First the need to touch at all eliminates a large chunk of attacks. Second the need to touch within 10–15 seconds eliminates a whole bunch more.

There would have to be some heavy-duty alignment of ducks going on to get past a touch requirement.

Even more if the target has touch AND PIN enabled.

Re: You don't want long-lived keys

#48

Post by entrope »

hsbauauvhabzb wrote: post #16
Dragging-Syrup wrote: post #14

Earlier quoted context omitted.

I’m sorry to be pedantic, that’s not exactly true. I agree in the sense that extracting hw based keys is next to impossible, but if your machine is compromised, there isn’t much stopping malware from using your hw based key (assuming 1. Left plugged in, 2. Unlocked with either ssh-agent or gpg-agent, and 3. You don’t have touch to auth turned on). Reduced risk? Absolutely. No risk? Absolutely not.

And if you want to be even more pedantic, shell access with a touch based key just means the attacker has to wait for you to auth, which makes touch based systems largely a waste of effort on the defenders part.

The touch based key I use only responds once per touch. If someone compromises the machine it's plugged into, the action I expected to complete won't complete. This means the compromise becomes immediately visible.

Re: You don't want long-lived keys

#49

Post by noAnswer »

XCSme wrote: post #40
gleenn wrote: post #10

After the Vercel hosting compromise and having to rotate a ton of keys recently, we are definitely implementing automated rotation of short lived keys. That was super painful.

But how do you do that without also having a long-lived key or access token to those services?

The long-lived credentials life inside a stripped down machine. Cron/lego/Ansible handles the renewal. The machines on the edge can't renew their keys themselves.

Re: You don't want long-lived keys

#50

Post by XCSme »

noAnswer wrote: post #49
XCSme wrote: post #40

Earlier quoted context omitted.

But how do you do that without also having a long-lived key or access token to those services?

The long-lived credentials life inside a stripped down machine. Cron/lego/Ansible handles the renewal. The machines on the edge can't renew their keys themselves.

Oh, this makes sense, so instead of "the app is rotating its keys" is more like "the keys in our app are being rotated by an external service".
Post reply on HN