Starting to feel like this is one of those things that people just blindly parrot all over the Internet without understanding the full context of the NIST guidelines, and as a result are actually causing many security problems.
You can’t take one recommendation that you like out of a whole body of work and start running around telling everyone to do this one thing. If you’re going to follow NIST, you need to do all of it. MFA is a big part of why complexity is reduced in the NIST guide, and you MUST have it if you’re going to remove complexity requirements. If you can’t have MFA for some reason (and yes, there are legitimate reasons for this), then you still need to use complexity, expiration, etc.
If for some reason you're stuck without MFA (and I appreciate why it happens), I can't agree short expiration adds value.
I've done brute force exercises. Some people always pick bad passwords. Tell an organisation to change every 60 days and a lot more people give up and land on May2019!.
Every time I start in a new organization, I spend some time to sit down and make a very strong password. The kind of password I would trust my retirement savings to. I'll sit down and dedicate a solid 30 minutes to transforming a bizarre but easy to remember phrase in 20-30 special characters with abbreviations instead of full words. Then I'll spend the time to commit it to muscle memory. I've done this probably 30 times over the past 20 years.
60 days later, maybe I make another new very strong password. 60 days after that, it's 8:15 and my computer is forcing me to update my password and I have an 8:30 meeting and now my password is asdfg;lkjh. 60 days later it's asdfg;lkjh1. And so on.
Password expiration dates are one of those things that just don't work with human beings. It's the "work harder, not smarter" approach to security. Somebody wrote it down once, and now everybody who came along later copied the same bad checklist and added more bad things to it. Instead of working to improve the practical security of their system, they work to adhere to their arbitrary checklist. It only makes sense from the most cynical Dilbert perspective.
I have a complicated google password - I use it no where else. I have a security key. In 12 years I've NEVER had to change my google account password AND I have not been hacked. This works well. Because google is resistant to brute force I don't even bother adding tons of weird special characters.
I worked at a govt related agency. They had to change passwords every 30 days and there was a dual password requirement (one to login to the VPN, the next for the app). Result?
- Many folks used a shared account with a public password emailed out every 30 days so everyone else did not have to deal with all the hassles of the password expiration dance. It was also super hard to onboard anyone new (ie, 3-4 months for staff with 12 month projects) This account ended up posted next to every computer.
The idea that making security so user unfriendly will makes folks like and use security is a ridiculous approach.
- Rate limit attempts
- Block after 4 tries for an hour, after 8 tries till a reset
- Screen against password lists
- Screen out other obviously bad (ie, too short etc).
- Allow hardware 2fa BUT allow staff to validate computer.
If you make your security policies into a problem for your people trying to do their work, they'll find ways to work around it.
That either means 1) your policies are misplaced and you need to relax then, or 2) you need to fire everybody who creatively works around them.
If your adversary is Mossad, the option 2 is the right one. If your adversary is not-Mossad, you can almost certainly have a security policy that people won't feel the need to work around.
There are, of course, shades of grey below "Mossad adversaries", but in my opinion at the upper end of that you have policies that include providing every employee with a good password manager, TOTP apps/devices, and/or USB 2FA keys - and choosing services which integrate properly with them.
"Change your password every X days" is an admission that you're going to leak passwords somehow, and that you only care about your data/systems enough to close the attack window down to X days. Which means you're screwed before you start, and may as well just turn everything off now.
They actually increased the password strength recommendations in the newest guidelines. Length counts more towards the security of the password than character classes which was increased.
Even without MFA the lack of password expiration is still considered best practice. It's not just parroting.
Separately though applying MFA anywhere possible is a best practice and should be separately encouraged from the strength and rotation policies.
This is simply not true. You can read SP800-63B Appendix A to see the rationale NIST provides for not enforcing password complexity; it has nothing to do with MFA, and NIST believes the old rules to be intrinsically bad.
> and as a result are actually causing many security problems.
That's completely contradictory to what the NIST guidelines state:
> The most notable form of these is composition rules, which require the user to choose passwords constructed using a mix of character types, such as at least one digit, uppercase letter, and symbol. However, analyses of breached password databases reveal that the benefit of such rules is not nearly as significant as initially thought [Policies], although the impact on usability and memorability is severe.
It depends on your definitions of easy to remember, hard to guess. 6 dictionary words with one random character is sufficiently complex to thwart planetary scale brute force attacks. It's much easier to remember than 20 random ascii characters.
I use the first three letters of each word in book titles/song lyrics and a number that means something to me like 186282 (speed of light in a vacuum in miles per second) for master passwords everything else is stored in Keepassxc.
aphiofsofdes68537513 is good enough and defeats a dictionary attack.
It requires discipline but I’m responsible for people’s PII at work and I treat that seriously.
For my personal stuff I keep a separate vault but with the same criteria.
I did something similar but you really should get some randomness in there. If an attacker is brute forcing solutions, it's conceivable, even likely, that attackers are going to smash together datasets like song lyrics or anything that comes up high in a google search to prioritize the search space. You could search millions of permutations of song lyrics for the 50% most popular songs on Spotify. You could do the same with text previews for books on Amazon. It probably wouldn't take that long for a targeted attacker.
If 2fa is involved it's a different story, but if you're talking about something liiiike the pass key of a private key that you can't guarantee is secret? Or if it's the private key used to do things like sign certificates? Please add randomness.
You can’t take one recommendation that you like out of a whole body of work and start running around telling everyone to do this one thing. If you’re going to follow NIST, you need to do all of it. MFA is a big part of why complexity is reduced in the NIST guide, and you MUST have it if you’re going to remove complexity requirements. If you can’t have MFA for some reason (and yes, there are legitimate reasons for this), then you still need to use complexity, expiration, etc.