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.
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.
> 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?
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.
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.
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.
Some magnificent systems have APP_KEY/APP_SECRET that is also used for cookie and database encryption. A frequent rotation of this is... inadequate... in systems with high traffic, to say the least, and hence I am sorry, but I do not believe it's the "usual" desire. As always, it depends on the context and transaction scope.
It didn't for me, and I got the starry space feel, but I noticed the repeating patterns.
Perhaps some movement is needed? I do recall some relatively similar cases saved, if interested:
1. Moving forward in space (JavaScript/JS): https://codepen.io/the_artwork/pen/zYEdxyo
2. Rotating in space (JS): https://codepen.io/the_artwork/pen/NWMRYJP
3. Rotating in space (CSS+JS): https://codepen.io/the_artwork/pen/PoeNyyy
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.
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.
> 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?
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.
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.
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.
Some magnificent systems have APP_KEY/APP_SECRET that is also used for cookie and database encryption. A frequent rotation of this is... inadequate... in systems with high traffic, to say the least, and hence I am sorry, but I do not believe it's the "usual" desire. As always, it depends on the context and transaction scope.
The fixed position background made it look like I had dust on my phone screen
It didn't for me, and I got the starry space feel, but I noticed the repeating patterns.
Perhaps some movement is needed? I do recall some relatively similar cases saved, if interested:
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".