Sigh.
Just got told by a company internal app that it's time to change my password.
Can we please stop with the fake #security? My password is a long string of randomly generated characters. Nobody's going to guess it any time soon.
Timeline
Post
Remote status
Context
8
@argv_minus_one I still believe in password rotation on long intervals (1 year min). Passwords that get spread across multiple systems (e.g. LDAP, OIDC) get used and abused and shoved into god knows what by people and it contains the damage to some extent of a lost first factor which happens all the time.
@7666 @argv_minus_one 1 year is reasonable and I would go even lower to 6 months at max. That said, there are companies that force password changes every 2 months and sometimes even faster. At that point it misses the point completely, because much more employees will just stick some number at the end or capitalize one letter and be done with it.
@phnt @argv_minus_one I am waiting for the inevitable screeching about how passwords should last forever and shouldn't be rotated until confirmed compromised and then I'll go "okay! now do that for TLS certificates!"
As for public CAs requiring TLS certificates to be rotated every 21 seconds, they're doing that because
1. OCSP has epically failed,
2. everybody had to go back to CRLs, and
3. in order for CRLs to not get monstrously huge, certificates must expire quickly so they can be quickly deleted from the CRL.
None of this applies to company internal stuff. Long-lived certificates are still fine in those environments.
@argv_minus_one @phnt Expiration and CRL entry are not the same. Certificates are timestamped with an expiration date which is approved by the CA. A CRL only gets updated when a certificate is explicitly revoked by the CA so that when clients reach out to the CRL they find the cert and stop trusting it, even if it is a 100% valid, in-date cert. You have this sideways.
The only reason why certificates, which generally live in a protected space untouched by users, have a more aggressive rotation period than passwords, is because of domain / resource transfers. At the time of signing, the domain / resource that was signed for could have changed hands, but the certificate would still be valid. This is where a CRL would come in, because prior to transfer you'd revoke the cert, but this is apparently too hard for CAs.
The correct path is to fix OCSP or CRL distribution, and not force the rest of us to fix it on their behalf by cycling certs like maniacs.
The only reason why certificates, which generally live in a protected space untouched by users, have a more aggressive rotation period than passwords, is because of domain / resource transfers. At the time of signing, the domain / resource that was signed for could have changed hands, but the certificate would still be valid. This is where a CRL would come in, because prior to transfer you'd revoke the cert, but this is apparently too hard for CAs.
The correct path is to fix OCSP or CRL distribution, and not force the rest of us to fix it on their behalf by cycling certs like maniacs.
@7666 @argv_minus_one You can't fix the system when browsers are basically the only ones steering it. The various hacks needed to make XMPP S2S connections not freak out after LE stopped issuing certs for client auth should have never existed in the first place.
Then there's also this: https://letsencrypt.org/2026/02/24/rate-limits-45-day-certs
Then there's also this: https://letsencrypt.org/2026/02/24/rate-limits-45-day-certs
@phnt @argv_minus_one I used to laugh at the US government and military for running their own CA and making people trust their root cert to access their sites. Now I'm having second thoughts.
Replies
0Fetching replies…