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

51–60 of 65 posts

Re: You don't want long-lived keys

#51

Post by lelanthran »

winstonwinston wrote: post #43
lelanthran wrote: post #39

Earlier quoted context omitted.

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

Understood. Not a bad idea.

Re: You don't want long-lived keys

#52

Post by akerl_ »

collabs wrote: post #44
Flimm wrote: post #42

Earlier quoted context omitted.

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?

> Long-lived production SSH keys may be copied around, hardcoded into configuration files, and potentially forgotten about until there is an incident. If you replace long-lived SSH keys with a pattern like EC2 instance connect, SSH keys become temporary credentials that require a recent authentication and authorization check.

Re: You don't want long-lived keys

#53

Post by orf »

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.

It’s like 12 lines of terraform to fully automate this, inside your existing IaC infrastructure. It’s not complex.

Re: You don't want long-lived keys

#55

Post by nightpool »

akerl_ wrote: post #34
nightpool wrote: post #33

Earlier quoted context omitted.

I disagree, I think increasing manual toil (having to log into Sentry every 6 months to put in a new Jira token) increases fatigue substantially for, in this case, next-to-no security benefit (Sentry never actually has any less access to Jira than it does in the long-lived token case, and any attacker who happens to compromise them is going to be gone well before six months is up anyway). Instead, the right approach…

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

Why? If Sentry gets compromised, it's the exact same outcome—your Jira tickets get mined for production credentials and downloaded for random. What does automated token management save here?

How long the Jira access lasts depends on you / Sentry detecting and solving the initial intrusion. It doesn't matter how long the Jira token itself lasts if the attackers have access to the database in which its stored or log files in which its been dumped or something like that.

Re: You don't want long-lived keys

#56

Post by ignoramous »

nazcan wrote: post #29

I find it interesting how this all comes down to what do you trust. Like.. why not <1 minute keys? Or 1-request?

> why not ... 1-request

You kid, but: https://en.wikipedia.org/wiki/Hash-based_cryptography

also: https://www.imperialviolet.org/2013/07/18/hashsig.html (2013).

Re: You don't want long-lived keys

#57

Post by akerl_ »

nightpool wrote: post #55
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.

Why? If Sentry gets compromised, it's the exact same outcome—your Jira tickets get mined for production credentials and downloaded for random. What does automated token management save here? How long the Jira access lasts depends on you / Sentry detecting and solving the initial intrusion. It doesn't matter how long the Jira token itself lasts if the attackers have access to the database in which its stored or log fi…

This assumes that the intrusion is persistent until Sentry catches it, that Sentry notifies me, that I successfully track all the places I have long-lived tokens that need to be rotated, etc.

Re: You don't want long-lived keys

#58

Post by kkl »

collabs wrote: post #22

Something I don't understand is the absolute phobia of service accounts. There are things that need to happen regardless of who is doing it. Emails need to get sent every day with reports, for example. Forcing these workflows into the nonsense security theater of "we can't have service accounts" is stupid and unproductive. So every time we fire or lay off the person whose name is on the automation, we need to rotate…

> "we can't have service accounts"

To be clear: This is not my position! I advocate for service accounts in my post:

> It is much harder to reason about, say, the security of an arbitrary Engineer's laptop than it is an EC2 instance that exists exclusively to tell KMS to sign something.

> So every time we fire or lay off the person whose name is on the automation, we need to rotate the keys?

If a person previously had access to the key and knowledge of the key gives you control over that automated workflow, is that key (and by extension that workflow) still worth trusting?

Re: You don't want long-lived keys

#59

Post by kkl »

cyberax wrote: post #20
kkl wrote: post #19

Earlier quoted context omitted.

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.

SSH CAs are not incompatible with my argument! An SSH CA can sign short-lived certificates for just-in-time generated keys.
Post reply on HN