[marshray]

It's not crazy to want a system to be designed such that it tends to converge to a secure state over time. We still have expiration dates on ID and credit cards and https certificates.

The advantages just didn't outweigh the disadvantages in this scenario.

[watwut]

You had 6 systems to log into, each with different requirements put on password. You are not supposed to share the password between system. Each system forces you to change the password in different schedule. And IT acts angry when you, predictably, forget password.

It did not converged to secure state, it necessary converged to everyone creating some predictable password system.

[II2II]

Expiration dates on passwords is probably a good idea, except that it encourages bad habits from the end user. It encouraged bad habits since the expiration period was typically very short. For example: I don't have much of an issue with the 1 year period at one workplace, but I do have an issue with the 3 month period at another work place. The other issue is that people have to manage many passwords. Heck, I worked at one place where each employee was supposed to access multiple systems and have different passwords on each system. (Never mind all of the passwords they have to manage outside of the workplace.)

Contrast that to the other examples you provided. All of them are typically valid for several years. In two of the cases, people are managing a limited number of pieces of plastic.

[Jerrrrrrry]

Apples to oranges.

Usernames are public now.

Back then, your username was public, and your password was assumed cracked/public, within a designated time-frame.

Your analogy would hold if when your cert expires, everyone gets to spoof it consequence free.

[freeone3000]

The cert can still be broken. The signatures are difficult, but not impossible, to break: it can and has been done with much older certificates, which means it will likely be doable to current certificates in a few years. In addition, certificate rotation allows for mandatory algorithm updates and certificate transparency logs. CT itself has exposed a few actors breaking the CA/B rules by backdating certificates with weaker encryption standards.

Certificate expiration, and cryptographic key rotation in general, works and is useful.

[bawolff]

> which means it will likely be doable to current certificates in a few years

It is extremely unlikely a modern certificate will be broken in the time horizon of a few years through a cryptography break.

All systems eventually fail, but i expect it will be several decades at the earliest before a modern certificate breaks from a crypto attack.

Keep in mind that md5 started to be warned against in 1996. It wasn't until 2012 that a malicious attack used md5's weakness. That is 16 years from warning to attack. At this stage we dont even know about any weaknesses about currently used crypto (except quantum stuff)

Rotating certificates is more about guarding against incorrectly issued and compromised certificates.

[j16sdiz]

Many modern crypto can be broken by nonce reuse.

Rotating certificates guard against bad PRNG and birthday paradox

[bawolff]

I disagree. I don't think rotating certificates would help against birthday attacks or bad prng.

Tbh, i have no idea which part you are attacking with the birthday attack in this specific context. It doesn't seem particularly relavent.

(At the risk of saying something stupid) - i was under the impression RSA did not use nonces, so i don't see how that is relavent for an rsa cert.

For an ecdsa cert, nonce reuse is pretty catastrophic. I fail to see how short lived certs help since the old certs don't magically disappear, they still exist and can be used in attacks even after being rotated.

[marshray]

If properly generated even the smallest RSA key sizes used in practice are still safe from birthday collisions.

But there have been several high-profile cases of bad RNGs generating multiple certs with RSA keys that had common factors. I think if you were put at risk by such a broken RNG, frequently re-generating your certs would tend to make things worse, not better.

[freeone3000]

Certs should be checked against a CRL and CT for revocation, and expired certs should never be accepted, for this reason among others.

[marshray]

Crypto breaks are a concern for sure, but typically the more short-term concern is server compromise. Cert revocation is not reliably checked by all clients, and sites may not even know to revoke it.

So it's essential that if/when a bad guy pops a single server that they don't get a secret that allows them to conduct further attacks against the site for some indefinite period into the future.

[Jerrrrrrry]

apple cider to apples

https://leahneukirchen.org/blog/archive/2019/10/ken-thompson...

[previous hn discussion]: https://news.ycombinator.com/item?id=21202905