> Mandatory password composition rules (excluding minimum length) and rotating passwords as well as all attempts at "replacing passwords" are inherintly dumb in my opinion.
I suspect that rotating passwords was a good idea at the time. There was some pretty poor security practices several decades ago, like sending passwords as clear text, which took decades to resolve. There are also people like to share passwords like candies. I'm not talking about sharing passwords to a streaming service you subscribe to, I'm talking about sharing access to critical resources with colleagues within an organization. I mean, it's still pretty bad which is why I disagree with them dismissing educating end users. Sure, some stuff can be resolved via technical means. They gave examples of that. Yet the social problems are rarely solvable via technical means (e.g. password sharing).
Much of the advice around passwords comes from time-sharing systems and predates the internet.
Rules like "don't write passwords down," "don't show them on the screen", and "change them every N days" all make a lot more sense if you're managing a bank branch open-plan office with hardwired terminals.
It's funny, writing passwords down is excellent advice on today's Internet.
Physical security is easy, who's gonna see inside your purse? How often does that get stolen? Phones and laptops are high-value targets for thieves, and if they're online there could be a vuln. Paper doesn't have RCE.
(That said, I use KeePass, because it's nice to have it synced and encrypted. These days only my KeePass password is written down.)
I was going to say such advice does have its limits. Then I remembered something: even though my current credit card does have a chip, the design suggests that it is primarily intended as a record of a "user id" and "password" (e.g. large easy to read numbers, rather than the embossed numbers intended to make impressions upon carbon copy forms that typically became impossible to read with wear).
Not exactly. Some transactions are cryptographically authenticated. "The algorithm" looks at those bits. Transactions with proper chips authentication are less likely to be flagged as fraud
Also the embossed numbers are not that common in countries outside the US. For quite a while the numbers themselves are also disappearing from the front. (If you even use the physical card rather than your phone)
I remember being mind-blown on my first trip to the US when a taxi driver took my card and literally carbon copied it manually (with a pencil and carbon copy booklet) on the spot.
I had been using my credit card for at least a decade (Europe) and it never ever occured to me that the embossed letters had any function other than aesthetic.
I had a food delivery guy use one in the US 2012/2013. It was like seeing a native tribe perform their traditional dance. It still blows my mind that chip + "signature" is a thing in the US. What good is a random indiscernible scribble on a tiny resistive touch screen as far as proving anything?
I could be wrong but I'm pretty sure it is also illegal to steal someone's credit card and use it. If you have already done that, I don't think the idea of scribbling illegally is going to warn anyone off. Chip+PIN is objectively far more secure. People used debit cards with swipe+PIN for decades just fine and chip+PIN is used in many other countries without an issue. It is just silly to keep using signature and acting like it does absolutely anything at all.
>I suspect that rotating passwords was a good idea at the time.
yes, when all password hashes were available to all users, and therefore had an expected bruteforce/expiration date.
It is just another evolutionary artifact from a developing technology complexed with messy humans.
Repeated truisms - especially in compsci, can be dangerous.
NIST has finally understood that complex password requirements decrease security, because nobody is attacking the entrophy space - they are attacking the post-it note/notepad text file instead.
This is actually a good example of an opposite case of Chesterton’s Fence
> NIST has finally understood that complex password requirements decrease security, because nobody is attacking the entrophy space - they are attacking the post-it note/notepad text file instead.
Actually NIST provide a detailed rationale for their advice [1]. Attackers very much are attacking the entropy space (credential stuffing with cracked passwords is the #1 technique used in breaches). But password change and complexity rules are pointless precisely because they don’t increase the entropy of the passwords. From NIST:
> As noted above, composition rules are commonly used in an attempt to increase the difficulty of guessing user-chosen passwords. Research has shown, however, that users respond in very predictable ways to the requirements imposed by composition rules [Policies]. For example, a user that might have chosen “password” as their password would be relatively likely to choose “Password1” if required to include an uppercase letter and a number, or “Password1!” if a symbol is also required.
> yes, when all password hashes were available to all users, and therefore had an expected bruteforce/expiration date.
Pretty much anyone I've spoken to candidly about rotating passwords has said that they use a basic change to derive the next password from the old. For example, incrementing a number and/or a letter. If that was as common a practise as I suspect, then rotating passwords doesn't add much security. It just meanstthat hackers had to go through a few common manipulation strategies after breaking the hash.
This is actually the third-order effect of itself, by itself.
Require frequent passwords, humans cheat, boom: your brute-force space just went from 1024 bits to 14, assuming you can onboard a red-team plant far enough to get the template for the default passwords.
If I know _bigcorp_ gives defaulted credentials in the format of [First Initial + Middle Initial + month_day] then not only can I piggyback a trivially-created IT/support ticket, I can also just guess that in 60, 90, 120 days, your credentials are the same, but the month_day - even if not correct, the search space is reduced by magnitudes.
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.
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.
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.
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.
> 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.
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.
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.
CT isn't used for revocation. CRLs aren't really a thing in practise. Refusing to accept expired certs is important for other reasons but won't save you from a reused ECDSA nonce.
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.
I suspect that rotating passwords was a good idea at the time. There was some pretty poor security practices several decades ago, like sending passwords as clear text, which took decades to resolve. There are also people like to share passwords like candies. I'm not talking about sharing passwords to a streaming service you subscribe to, I'm talking about sharing access to critical resources with colleagues within an organization. I mean, it's still pretty bad which is why I disagree with them dismissing educating end users. Sure, some stuff can be resolved via technical means. They gave examples of that. Yet the social problems are rarely solvable via technical means (e.g. password sharing).