| To the people responding to this saying that "expiry is mandatory", you're missing a key aspect: expiry is mandatory for uncontrolled secrets. Passwords and API Keys are uncontrolled. Once they've leaked, they're "out there", and you can't know where they've been copied, stored, and who has them. There is no central, authoritative list of "currently held credentials". They're literally "bearer tokens", like cash-in-hand versus something held in an account that's recorded on a ledger. This makes password-like credentials inherently risky, so people work around these issues by: - Restricting network access - Restricting the time for which they are valid - Restricting who can get any access at all. These restrictions then "get in the way", even for legitimate use. Network access restriction mean that everyone has to be on the VPN. I mean the VPN, because you can't be on two VPNs (in general). This limits business activities such as querying across federated systems. All "access control" now involves the network team. The guys "running cables" have to be involved in database access! Time restrictions mean that as things expire, they break. One year expiry is just long enough that people have moved on from their six-month contracts, and the new guy has no idea why everything went down at 4:55pm on a Friday. Sure, you can automate the rotation away, but then the automation system itself inherits the same security boundary as the tokens it is managing. You can't automate your way out of this, because then it becomes turtles all the way down.[1] Restricting who can get any access at all because of the legitimate fear that they will leak their API keys hampers productivity. If developers can't be trusted not to copy-paste keys into their code[2], then they won't be given keys at all. This limits what they can do. Similarly, even read-only access will be restricted, so you end up with systems where data is copied over-and-over into other systems because direct access "wasn't an option". Generally my advice to architects and developers is to avoid passwords or API Keys like the plague. Use something like Azure Active Directory with managed user identities, which allow "secretless" access. This access is also self-documenting, with a central authority tracking who has access. You can't "copy" a managed identity or "run off with it". There is no way to paste one of these into Git, or leave it on a laptop that is being disposed of. [1] One particularly problematic security risk with things like GitHub PATs is due to GitHub Actions. Previously, Git was "just code", posing only a slightly greater risk than documentation. Now, it's managing deployments of apps, and their secrets, making it super dangerous to give anyone access to the repo! There have been several major breaches because of this. [2] In the last year or so working with over a dozen developers moving into cloud apps, I observed literally every single one of them pasting API Keys or similar secrets directly into the code and then checking that in to Git. |