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

11–20 of 65 posts

Re: You don't want long-lived keys

#11

Post by cassianoleal »

nitwit005 wrote: post #7

> If you assume that someone is constantly trying to guess a key or password, the likelihood that they guess correctly grows over time. If they can brute force the password or key, the rotation will, at best, force them to do it multiple times. You'll see more improvement from just adding another couple of characters to the length.

Fair enough, but that doesn't protect you in case of a leak. If you're going to solve for the leak anyway, is it worth it to solve for brute force in isolation? You can always add another couple of characters. At which point do you stop?

Re: You don't want long-lived keys

#12

Post by cyberax »

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".

Re: You don't want long-lived keys

#13

Post by sandeepkd »

I think the take on key lifetime is premature which taking into consideration

1. How key is used

2. Whats the threat vector

3. Cost of key rotation

4. Cost of key verification

At the end of the day its a trade off, the business use case, your expertise and the risk have to be evaluated together

Re: You don't want long-lived keys

#14

Post by Dragging-Syrup »

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.

Re: You don't want long-lived keys

#15

Post by cyberax »

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.

Sure. They can use my key while my machine is compromised, but even then I won't _need_ to rotate it after the compromise is cleared.

It still would be a good idea just to make sure that it's easier to analyze logs, but it's not strictly needed.

Re: You don't want long-lived keys

#16

Post by hsbauauvhabzb »

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.

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.

Re: You don't want long-lived keys

#17

Post by tptacek »

nightpool wrote: post #6

Okay but now how do you recommend I hook up my Sentry instance to create tickets in Jira, now that Jira has deprecated long-lived keys and I have to refresh my token every 6 weeks or whatever. It needs long-lived access . Whether that comes in the form of a OAuth refresh token or a key is not particularly interesting or important, IMO.

You do what you can. Eliminating long-lived keys isn't always possible; you set up rotation instead.

Re: You don't want long-lived keys

#18

Post by bloppe »

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.

Never apologize for pedantry here

Re: You don't want long-lived keys

#19

Post by kkl »

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".

Part of the threat model for an Engineering team is that people come and go. They move teams which have different levels of access. They leave the organization, in most cases, on good terms. I want to set up infrastructure where I don't need to remember that your SSH pubkey is baked into production configuration after you leave the company.

There are several options for setting up per-connection keys that are dispensed to users through the company SSO. That setup means you don't need to maintain separate infrastructure for (de-)provisioning SSH keys.

Re: You don't want long-lived keys

#20

Post by cyberax »

kkl wrote: post #19
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".

Part of the threat model for an Engineering team is that people come and go. They move teams which have different levels of access. They leave the organization, in most cases, on good terms. I want to set up infrastructure where I don't need to remember that your SSH pubkey is baked into production configuration after you leave the company. There are several options for setting up per-connection keys that are dispens…

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.

Post reply on HN