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.

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.

A case where I am fine with long lived keys is a public static blog that has no sensitive data and does not allow user contribution of any kind. A site so static and public I can check 100% of the files and web server configuration into a public git repo minus the private key. That's just my take and my personal preference of course.

Honestly I would use a self signed certificate if there was a way to tell the browser it is a static blog and not to add friction to the user experience. It's not like LE is adding identity verification to the process any more than a self signed certificate would. It would be nifty if there was some naming standard that could tell the browser a blog is absolutely static and free of anything sensitive like staticblog.domain.tld so that it could dial down the you are about to be pwned! which I am sure some would abuse but that's fine, let them.

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

Agreed! Been working on infra for an early-stage company recently and it's been awesome using OIDC and IRSA (or WIF if you're on google) for as many things as possible. Basically, there are no permanent keys for anything.

Slightly annoying to have to wrap some clis in scripts that generate the short-lived token, but it feels really magical to have services securely calling each other without any explicit keys or password to even store in our vault.

Lots of cool benefits --- for instance, we ran the compromised Trivy github action a few weeks ago, but our Github Actions had 0 keys for it to leak! Also really great that I don't have to worry about rotating shared credentials on short notice if an engineer on my team decides to leave the company.

Even still, I prefer the simplicity of API keys. The mental overhead is low, and having to explain the concept to customers is zero. Rotating keys is not great but the tedium of it is preferred over the labyrinthian shenanigans of getting whatever the hot new security style of the week setup is.

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.

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

one thing that always felt off to me is how much focus goes into how access is granted and rotated, and much less into what actually happens after that access is used

even with short-lived or well-scoped credentials, the behavior behind them can still be pretty opaque depending on the system

so you reduce risk on access, but what happens after can still be hard to reason about or observe

What about dynamic credentials. Why can't we deploy HSM(hardware security module), they are so much more affordable now. We then deploy fido2 keys, have our long lived keys in there and have HSM serve as dynamic credentials server.

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

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

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 the keys? What is the benefit here?

If you are screaming "managed identity" here, I have a bridge to sell you because clearly even Microsoft has not been able to figure out or implement managed identities for internal workloads... Well not as of 2022, at least.

You dont usually want keys at all. At least in the sense of copy this key from system A and paste it in this other place system B. Usually CI. You want some continual method of authentication and authorization.

The fixed position background made it look like I had dust on my phone screen

Not a single mention of SPIRE thus far, sus

I'm still having problems trusting my compiler.

Where possible I prefer to implement signed policy objects. Then I can constrain access based on source IP and other request parameters. You can also easily implement an expiration date if you feel any particular application requires it, but some simple constraints may be useful enough that you might skip this in the majority of server to server applications.

This not only provides security but provides some resistance to bugs in your code which either call services incorrectly or call the incorrect methods of a service. I've avoided accidental data deletions and other painful events because my policy document did not allow this action. It turns these bugs into failures at the security perimeter.

I've used this concept in a few user applications as well. Typically those documents will always have expiration dates and I'll provide a "license" API which allows a single authenticated client request to retrieve an appropriate policy document. This is particularly nice when you want to implement a service across different providers or want to avoid downstream authentication overhead.

[dead]