One of the funnier implications of the "It's an older code, sir, but it checks out" line from Star Wars is that credential revocation is a much more difficult problem than artificial gravity, integrated bioprostheses, interstellar faster-than-light travel or hard-AI.
Remember, that line is spoken by _Admiral_ Piett; so - long ago, in a galaxy far far away - fleet-level auth and cert management was important enough that it was one of a flag officer's main duties.
https://infosec.exchange/@david_chisnall/117319592191698274Open quoted post Quoting
Please stop enforcing mandatory time limits on credentials that are trivial to revoke!
The point of mandatory expiration is that revocation happens eventually. In the case of a compromise and leak of that credential, an attacker has a guaranteed sunset when their stolen credentials will stop working. This is sometimes a useful property.
For example, checking certificate revocation lists on every TLS session is slow. It's common for clients to skip this and rely on revocation sets that are pushed out during software updates. Short lifespans here serve to optimise the performance of revocation lists / sets: if your certificate lifetime is five days and you revoke it, after five days it can be deleted from revocation lists. Scale this to the number of certificates issued across the entire Internet and that's a big saving.
But the big down side of requiring frequent generation of short-lived credentials is that the credentials needed to generate that credential (which, by definition, are more privileged) are frequently accessed.
If I am generating a token to go into some release flow and I can do it once via a cumbersome process that requires multiple rounds of authentication and then put it in some secure credential store where it's accessed only from an ephemeral VM doing my release flow, then I don't care about the effort of generating the token. I do it once and, in the happy case, forget about it. If there's a trivial mechanism for revoking it, we're done: if there's evidence of compromise, revoke it and go through the slow process again.
But if that token expires every 30-90 days, I need to automate generating it. Which means that some automated process that is likely to be as vulnerable as the token itself now has access to the credentials required to mint the token. And that's introduced additional complexity without introducing additional security.
TL;DR: If you have an expiration policy for credentials, make sure that you have a threat model that it is intended to address and that you understand the operational complexity that you're introducing and any security weaknesses that this is will cause.
Open quoted post 
🇵🇷
