You don't want long-lived keys(argemma.com) |
You don't want long-lived keys(argemma.com) |
- https://docs.gitlab.com/ci/secrets/id_token_authentication/#... - https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_pr...
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.
In some cases this makes rotation a big event to be avoided because costs are higher than gains.
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.
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".
It still would be a good idea just to make sure that it's easier to analyze logs, but it's not strictly needed.
Except the three pretty major things that do stop malware that you mentioned ;)
Perhaps especially "3. You don’t have touch to auth turned on".
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.
The target machines then just need to put the CA cert in the authorized_keys files.
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.
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.
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.
You kid, but: https://en.wikipedia.org/wiki/Hash-based_cryptography
also: https://www.imperialviolet.org/2013/07/18/hashsig.html (2013).
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
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
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.
Seems like it's just Microsoft that cannot figure it out. AWS had roles forever, fully supported from web console or CLI. But when I request Azure service account, I am handed username and password.
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?
Related:
- 1. https://symfony.com/doc/current/reference/configuration/framework.html#configuration-framework-secret
- 2. https://laravel.com/docs/13.x/encryption#gracefully-rotating-encryption-keysPerhaps 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/PoeNyyyAnd if you want to be EVEN more pedantic, on most touch-based keys, you have to touch within 10–15 seconds otherwise it times out.
So it is not a waste of effort at all. First the need to touch at all eliminates a large chunk of attacks. Second the need to touch within 10–15 seconds eliminates a whole bunch more.
There would have to be some heavy-duty alignment of ducks going on to get past a touch requirement.
Even more if the target has touch AND PIN enabled.
The word "just" is doing a lot of work there. You update authorized_keys every hour for your entire fleet?
It is the user machine that needs new certificate signed by the CA once the short-lived one expires.
Ahh, now you have three problems…hrm
Its still early, but my aim for this project is to be the simplest/easiest "SSH login via SSO" available on the market. open for feedback & suggestion
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.
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.
What’s your excuse?