3 ms·
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, th
by bostik 5y ago
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.
- mcny 5y ago> 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?
- bostik 5y agoWell, 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.