You don't want long-lived keys
This post dives deep into the inherent liabilities of long-lived keys, highlighting how they compound risks over time. It advocates for ephemeral keys as a superior security engineering solution, offering practical examples like EC2 Instance Connect and trusted publishers. Hacker News appreciated the pragmatic advice and shared their own war stories and best practices in key management.
The Lowdown
The article argues that long-lived keys are significant security liabilities that grow risk over time. Factors like employee turnover, increasing brute-force probability, and cryptographic usage limits all contribute to this vulnerability. While scope reduction and diligent rotation are traditional countermeasures, the author points out the operational pain and potential for outages associated with manual key rotation.
The core thesis is that systems built around ephemeral keys (valid for a day or less) inherently manage this risk better, effectively making rotation a built-in feature. Specific examples provided include:
- Replacing long-lived SSH keys with patterns like EC2 Instance Connect for temporary, authenticated access.
- Utilizing trusted publishers for package repositories (e.g., PyPI) to generate short-lived credentials via CI/CD workflows.
- Leveraging SSO to replace static user passwords with short-lived authentication assertions from identity providers.
The author acknowledges that eliminating all long-lived keys isn't always possible, especially for foundational components like the key signing SSO assertions. However, reducing their number allows for concentrated security efforts, enabling more rigorous hardening and management of the remaining critical long-lived keys. This involves limiting their scope, carefully reasoning about their maximum lifetime, and performing quarterly rotations to maintain operational muscle. The ultimate goal is to consolidate this necessary, toilsome rigor within dedicated security groups, solving it once for everyone else.
The Gossip
Key Critiques and Contextual Complexities
Commenters offered nuanced perspectives on the article's strong stance against long-lived keys. Many agreed with the premise but highlighted scenarios where long-lived keys are unavoidable or preferred, particularly for hardware-rooted asymmetric keys where compromise risk is lower. The discussion also touched on the trade-offs involved, suggesting that key length might be more critical than rotation for brute-force resistance, and that the 'cost of rotation' needs to be weighed against the 'cost of compromise' for specific business cases and threat models. Some pointed out legacy systems where fundamental application secrets (e.g., for encryption) are extremely difficult to rotate without significant re-architecture or downtime.
Ephemeral Success Stories and Strategies
Many in the community resonated with the pain points of long-lived keys and shared positive experiences transitioning to ephemeral or dynamic credentialing systems. Several cited recent security incidents (like the Vercel compromise) as catalysts for adopting automated, short-lived key rotation. Modern solutions like OIDC, AWS IAM Roles for Service Accounts (IRSA), and Workload Identity Federation (WIF) were frequently mentioned as effective ways to eliminate permanent keys, even for service-to-service communication. The general consensus was a strong preference for continuous authentication and authorization mechanisms over static keys.
Operational Hurdles and Headaches
While enthusiastic about the benefits, some users also brought up the practical challenges of implementing ephemeral key strategies, especially when dealing with external integrations or older systems. Specific frustrations included applications that require refresh tokens every few weeks or `APP_KEY`/`APP_SECRET` values that are deeply embedded and difficult to rotate without significant operational overhead or risk of breaking existing functionality. This highlighted that while the ideal is ephemeral, the reality often involves managing imperfect, legacy-bound situations.