Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

There’s no need to change passwords if they're robust, unique and not breached

tidbits.com

Post reply on HN
Print view View original

31–40 of 288 posts

Re: There’s no need to change passwords if they're robust, unique and not breached

#31

Post by the_snooze »

e1g wrote: post #28

In the USA, the latest government guidance from Jan 2022 is that "Password policies MUST NOT require use of special characters or regular rotation". [1] This is a strong upgrade from earlier softer language like "don't have to/should not". In practice, this new rule contradicts almost every InfoSec stance out there, but all government agencies must comply with this new rule by the end of the year, so expect lots of c…

The "character class" requirement really doesn't add much security. And the "password rotation" policy can actually result in worse passwords than otherwise. Those measures were effectively just folk medicine from the days when the threat was thought to be someone manually trying to brute-force your password at your terminal.

Re: There’s no need to change passwords if they're robust, unique and not breached

#32

Post by tialaramex »

andrey_utkin wrote: post #12

I am unconvinced. What about persistent password bruteforcing? Rate limits? OK, bruteforcing is happening within those rate limits. That's how the password rots - it becomes less of a secret as many values are tried. Key material rotation seems to be a sensible practice in general.

> it becomes less of a secret as many values are tried.

Not meaningfully. Let's take my Hacker News password and we'll imagine you happen to know (somehow) exactly what the format is, so then you start guessing.

And we'll imagine you can make 1 billion login attempts per second, which in fact I'd guess will make dang pretty unhappy 'cos the servers won't like that.

And maybe you get to do this on a billion computers, and for a billion seconds, again I'm thinking somebody would notice and stop you, but let's just say...

At the end of all that you've still got orders of magnitude less chance of guessing my password, for this web site correctly than a random ticket buyer has of winning the jackpot in a typical state or national lottery game. Get a new hobby.

I think people struggle with the numbers involved. Even astronomical numbers are too small, because astronomical numbers involve practical things, like how quickly light travels and maths does not need to be practical.

Re: There’s no need to change passwords if they're robust, unique and not breached

#33

Post by new_guy »

q3k wrote: post #21
andrey_utkin wrote: post #12

I am unconvinced. What about persistent password bruteforcing? Rate limits? OK, bruteforcing is happening within those rate limits. That's how the password rots - it becomes less of a secret as many values are tried. Key material rotation seems to be a sensible practice in general.

With a ratelimit of 60 attempts per minute (which is significantly higher than any user would legitimately ever need) you're looking at thousands of years to bruteforce a random 6 character alphanumeric password.

This seems remarkably unintuitive, but the math checks out.

(26+10)⁶ = 2,176,782,336

1,450 minutes a day

2,176,782,336 / (1,450 * 60) = ~25,000 years

Re: There’s no need to change passwords if they're robust, unique and not breached

#34

Post by AnIdiotOnTheNet »

e1g wrote: post #28

In the USA, the latest government guidance from Jan 2022 is that "Password policies MUST NOT require use of special characters or regular rotation". [1] This is a strong upgrade from earlier softer language like "don't have to/should not". In practice, this new rule contradicts almost every InfoSec stance out there, but all government agencies must comply with this new rule by the end of the year, so expect lots of c…

> In practice, this new rule contradicts almost every InfoSec stance out there

Yeah, that's because those stances are not based in fact, but repeated bad ideas left over from the 70s and 80s.

Re: There’s no need to change passwords if they're robust, unique and not breached

#35

Post by _wldu »

ryangittins wrote: post #10
nend wrote: post #6

Earlier quoted context omitted.

This has been a standard IT policy for companies in the US for like 20 years. Probably 3/4 of the companies I've worked at over that time anyway.

NIST actually changed their recommendation relatively recently and no longer suggests periodic password changes without reason. > 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. Source: https://pages.nist.gov/800-63-3/sp800-63b.html#memsecretver

Yes, and I believe they initially made this change in June 2017 (almost 5 years ago now). IT audit/compliance is typically 5 to 10 years behind best security practices and some standards are even slower to catch up.

Re: There’s no need to change passwords if they're robust, unique and not breached

#36

Post by jffry »

q3k wrote: post #21
andrey_utkin wrote: post #12

I am unconvinced. What about persistent password bruteforcing? Rate limits? OK, bruteforcing is happening within those rate limits. That's how the password rots - it becomes less of a secret as many values are tried. Key material rotation seems to be a sensible practice in general.

With a ratelimit of 60 attempts per minute (which is significantly higher than any user would legitimately ever need) you're looking at thousands of years to bruteforce a random 6 character alphanumeric password.

Yeah and if your system allows an attacker to sustain one attempt per second into perpetuity, then you need to improve your system. Just be wary of DOS attacks against users when considering things like per-user limits (versus per-IP limits)

Re: There’s no need to change passwords if they're robust, unique and not breached

#37

Post by Moodles »

A lot of users will simply change their passwords by appending a 1, 2, 3, etc. at the end. Presumably if old passwords did sour and become compromised then Hashcat would easily crack the minor tweak on the new password.

To be fair to these companies, the reason they do passwords so terribly is because of such poor guidance and standards in the past. Even now NIST has SP 800-132 for guidance on generating a cryptographic key from a password for storage applications, which is different and often confused with guidance on storing passwords (which they don’t give advice for). There they say to use PBKDF. Also, compliance standards such as PCI don’t allow for modern storage like Argon2, so at best companies use something like bcrypt.

Re: There’s no need to change passwords if they're robust, unique and not breached

#38

Post by ryangittins »

_wldu wrote: post #35
ryangittins wrote: post #10

Earlier quoted context omitted.

NIST actually changed their recommendation relatively recently and no longer suggests periodic password changes without reason. > 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. Source: https://pages.nist.gov/800-63-3/sp800-63b.html#memsecretver

Yes, and I believe they initially made this change in June 2017 (almost 5 years ago now). IT audit/compliance is typically 5 to 10 years behind best security practices and some standards are even slower to catch up.

Welp, I guess I am now old enough that 5 years ago "relatively recently." :/

Re: There’s no need to change passwords if they're robust, unique and not breached

#40

Post by daneel_w »

Cr0s wrote: post #2

Do people even actually change their passwords when there is no need to do so, just because the password is old?

For certain sensitive websites (e.g. domain registrar) I change passwords once a year or so, because there's really no guarantee that administration would 1) notice a breach early or at all, 2) fully understand the scope/severity, or 3) even notify their users about a breach.
Post reply on HN