Slashdot Mirror
NIST's Draft To Remove Periodic Password Change Requirements Gets Vendors' Approval (csoonline.com)
An anonymous reader writes: A recently released draft of the National Institute of Standards and Technology's digital identity guidelines has met with approval by vendors. The draft guidelines revise password security recommendations and altering many of the standards and best practices security professionals use when forming policies for their companies. The new framework recommends, among other things: "Remove periodic password change requirements." There have been multiple studies that have shown requiring frequent password changes to actually be counterproductive to good password security, said Mike Wilson, founder of PasswordPing. NIST said this guideline was suggested because passwords should be changed when a user wants to change it or if there is indication of breach.
I welcome the return to sanity.
The point of periodic password changes is to protect against an *UNKNOWN* breach, where the password has been compromised and the user doesn't know. Is there some other method of mitigation for this attack?
My previous position was in a company that had a 45 day password expiry policy. My password was only as complex as it had to be to fit the rule but wasn't very good.
My current position has a 6 month expiry. I use a much stronger password.
This is common sense to me.
LK
"Hi. This is my friend, Jack Shit, and you don't know him." - Lord Kano
Randomly generated password of any given strength has the same probability of being guessed as any another equivalently strong random password. Only reason for strong password change is breach. Oh, and, my favourite pet peeve: common requirement that passwords must have some minimum number of characters from few subsets of all printable characters actually makes them much weaker.
If you have a really well-connected single sign on environment in place, standardizing on a single password that you have to change periodically makes sense. Where it breaks down is when you have a million passwords scattered across different services (internal or external.) If you have to change those over and over, you end up recycling passwords or writing them down, or storing them in a password vault tool (which is a bad idea given how many vulnerabilities have come to light on those.)
In fact, with SSO systems like Google or Azure AD, it makes sense to protect that single key much more carefully than an individual password. For example, if someone guessed my corporate account's password or found a way to steal information from Microsoft without them knowing (or telling anyone,) my Azure AD account has a lot of access -- off the top of my head, from the naked Internet I can access my Exchange email, OneDrive, all the Azure resources I have control over, most of my HR vital data, access to Internet-facing applications, access to my MSDN and volume licensing stuff from Microsoft, and the list goes on. I'm OK with changing that password pretty frequently. If I had 50 of them to remember, not so much.
The fact that the standards are being updated to reflect that it's much harder to steal passwords from properly secured systems these days and crack them offline is good though. Corporate security types tend to follow these rules verbatim regardless of whether they make operational sense.
Thank goodness. Frequent changes entrench bad habits and culture. People are constantly getting locked out, forgetting password. Your culture becomes one of frequent password resets with idiotic questions to verify identity. These questions are usually trivially guessable/facebookable/googleable especially since people forget these all the time too. Many helpdesks will reset passwords via phone without verifying identity since they do it constantly with frustrated resentful users. Make passwords durable. Changing it without knowing the old one should be a big difficult deal.
Man, you really need that seminar!
Biometrics are great for identification, but very, very poor for authentication. As soon as this finally settles in, we can start talking about using it.
We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
Most users are expected to know 22 paswords
Seriously, fuck you, to any site admin who contributes to this.
Real people can remember 2 or three passwords and that is all they will bother to remember. They will have maybe 2 long term secure passwords for things they personally value (and guess what, work isn't one of those things) and they will reuse the same password or variants of it on every single other system they use. No user will memorize a new password if they are expected to change it regularly. They will create the easiest password possible that meets the systems requirements.
This is universal and everyone knows it. The previous company I worked for was a well trusted security company with a policy of passwords that had to change every 90 days, use an uppercase letter, lower case letter, number, symbol and had to be at least 8 characters. I did a survey. Over 2 thirds of engineers and 6 out of 6 in HR admitted their password was a common 6 letter English word, first letter capitalized, a symbol and a number that they incremented.
1) If that is a big concern, use multi-factor. When real authentication security is important, multi-factor is important. You can't go and say an account is super important and needs high levels of protection but then refuse to go multi-factor.
2) How long are you ok with an adversary having access to your systems? Is 6 months ok? 12? Those are usually what you see password change requirements set at. Are you really ok with someone having unauthorized access to your systems for 12 months, but that's it, any longer is an issue? Of course not. But to change it often enough to keep an unknown compromise to what you'd consider acceptable users would need to change passwords multiple times a day.