Nobody actually cares about the security of expiring passwords, it's just a line item on a checklist of official processes. And the people auditing it don't visit in person
“Verifiers SHOULD NOT require memorized secrets to be changed arbitrarily (e.g., periodically). However, verifiers SHALL force a change if there is evidence of compromise of the authenticator.”
Users tend to choose weaker memorized secrets when they know that they will have to change them in the near future. When those changes do occur, they often select a secret that is similar to their old memorized secret by applying a set of common transformations such as increasing a number in the password. This practice provides a false sense of security if any of the previous secrets has been compromised since attackers can apply these same common transformations. But if there is evidence that the memorized secret has been compromised, such as by a breach of the verifier’s hashed password database or observed fraudulent activity, subscribers should be required to change their memorized secrets. However, this event-based change should occur rarely, so that they are less motivated to choose a weak secret with the knowledge that it will only be used for a limited period of time.
Both NIST and NCSC now actively discourage password expiration. And it took them only what, 30 years, to catch up with real-world best practices?
That said, there is a place for 30-day rotation. That's when the so-called "password" is actually a shared secret for extremely high-value systems. Payment gateways, for example.
> That said, there is a place for 30-day rotation. That's when the so-called "password" is actually a shared secret for extremely high-value systems. Payment gateways, for example.
Should we even attempt to let the user define such shared secrets? If 30-day rotation is good, surely 30 second rotation is better? Perhaps we can replace such "passwords" with some kind of one time PIN (OTP) or some generated pass phrase only valid for n minutes?
Well, in this shared-secret case we're talking about "symmetric signing keys" (really: MAC keys). Those types of keys are not defined by the users, they are issued by the party you're connecting to and delivered over a known, reasonably secure out-of-band mechanism.
I am all for having transient secrets, but without an extremely well integrated and robust vault they would be unmanageable. Plus asymmetric handshakes are computationally really expensive, so you don't do them all the time.[ß] The 30-day rotation period for these types of secrets is merely a reasonable compromise between "assume all shared secrets will be compromised" and the human factor.
ß: a friend set up a dedicated payment gateway device for a UK challenger bank. For just one card issuer. That thing can supposedly run at 10Gb line rate, so doing asymmetric crypto frequently would murder performance and latency.
I've been confronted with exactly this a short while ago, and even produced Microsoft's official stance on this (against). But in the end, their argument really boiled down to "but my checklist says so".
Microsoft's [0] first entry of "Common approaches and their negative impacts". With a reference to the FTC website. [1]
This is so infuriating. NIST has been advising against it for years by now and even Microsoft switched the official stance last year or so, but it still keeps being done out of inertia. It's also still in the AWS best practices (I unsuccessfully tried to argue against introducing it for our accounts).
Though, to be honest, at this point I believe that humanity should just abandon passwords for all but the most unimportant of things (e.g. your account on some hobbyist forum), at this point they just have too many downsides and most people seem to be unable to handle them properly.
