The idea of a secret is much like a password, it allows a service to authenticate without using keys or cryptography. It’s a simple comparison. “Does your secret match my secret?” When sent over encrypted channels, secrets can be a simple and effective means to provide authentication. Is PKI better? For sure.
In the recent past, Azure forced “secrets” to have expiry dates. The issue of this article isn’t how secure secrets are, or whether they should be used at all. This article is about the fact that secrets expire.
This article isn’t going to change anyone’s mind. I’m just a grump cybersecurity guy venting. You see, when something expires, something breaks. When something breaks, the workflow breaks. And when the workflow breaks, things are serious and money is lost (usually).
Much like when a webserver’s certificate expires, things break, people are interrupted in their work, money stops flowing, and someone ultimately will pay.
So why do we expire things? Because we keep losing our keys. To reduce the attack window. For certificates, we expire them because the revocation process is largely considered broken. And if we can’t revoke a certificate, we have a security risk.
So why do we need to revoke a certificate? Presumably because we lost the key – it was stolen, or exposed, or otherwise can’t be trusted any more. At the end of the day, someone who has both the key and the certificate could theoretically impersonate the proper owner. I say “theoretically” because the target still needs to visit the malicious site. But let’s consider that a given for now. Certificates need to be revokable. But the revocation mechanism is broken and the solution is to expire them. And expire them often. In fact, we’re in the process as a community to shorten the expiry to just days. Before you know it, we’ll have PFS (perfect forward security) for certificates – where the same certificate can’t be used for more than one session. I’m joking. I hope.
It’s all about protecting the person using the web browser. At least, when talking about certificates, protecting the user is the objective.
So we expire certificates because we keep losing keys. Ok, fine. But why do we expire secrets? Basically the same reason, they could be compromised or exposed. But given that secrets are used mostly for API’s these days (I haven’t done a study on this, it’s just a gut feeling) so the requirement to have a working revocation system isn’t necessary, you’d simply change the secret at both the client and API end. So wire expire them? Because, like with certificates and their fellow keys, we keep losing them.
I’m seeing a trend here.
I have a solution. A solution for secrets that would otherwise expire. Let’s allow non-expiring keys. Instead of them expiring, we can have a reminder to change them – call it a soft expiry. The reminder would allow us to forget to change the secret but the reminder would allow us to say “Yea, we need to do that” and would you believe it, things don’t break.
Expiries that aren’t actions have a 100% change of breaking something. Expiries that are essentially a reminder (a soft break) would allow us to respond after forgetting for a few days, without the business grinding to a halt.
There’s arguments for automation, and it’s good. But every system administrator has a story about when they got caught by surprise by something (usually a certificate) expiring. Someone didn’t document it. An automation playbook failed or didn’t run. There’s always a reason but it doesn’t matter. The boss calls and says “We’re losing money!”. The devils-advocate would say “It’s better to lose money than lose the business through an exploited key/certificate/secret!” maybe (it depends on the actual outcome) and I would generally agree, but I’m not saying secrets shouldn’t be changed, I’m saying they [secrets] should be changed in a controlled way that doesn’t guarantee a system failure, process failure or business failure just because someone forgot or an automation failed.