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.
You don't want long-lived keys
31–40 of 65 posts
Re: You don't want long-lived keys
#32I find it interesting how this all comes down to what do you trust. Like.. why not <1 minute keys? Or 1-request?
We do a lot of request signing (think AWS sigv4a) which practically speaking amounts to 1-request.
Re: You don't want long-lived keys
#33Okay 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.
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 in this case is to worry less about the length of the token and more about making sure the token is properly scoped. If Sentry is only used for creating issues, then it should have write-only access, maybe with optional limited access to the tickets it creates to fetch status updates. That would make it significantly less valuable to attackers, without increasing manual toil at all, but I don't know any SaaS provider (except fly, of course) that supports such fine-grained tokens as this. Moving from a 10 year token to a 6 month token doesn't really move the needle for most services.
Re: You don't want long-lived keys
#34Earlier quoted context omitted.
You do what you can. Eliminating long-lived keys isn't always possible; you set up rotation instead.
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.
Re: You don't want long-lived keys
#35Earlier 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.
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.
Re: You don't want long-lived keys
#36My 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.
Re: You don't want long-lived keys
#37Okay 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.
OIDC with JWT doesnt need any long lived tokens. For example, I can safely grant gitlab the ability to push a container to ECR just using a short-lived token that gitlab itself issues. So the answer might be to ask your sentry/jira support rep to fast track supporting OIDC JWTs.
- https://docs.gitlab.com/ci/secrets/id_token_authentication/#... - https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_pr...
Re: You don't want long-lived keys
#38Earlier quoted context omitted.
You do what you can. Eliminating long-lived keys isn't always possible; you set up rotation instead.
Does having to refresh the key every 6 weeks instead of every year or whatever actually make a meaningful difference security-wise?
If the key becomes compromised, rotating the key sooner means you potentially limit the damage from unauthorised access.
Re: You don't want long-lived keys
#39Earlier 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.
> 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?
Re: You don't want long-lived keys
#40After 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?