Back to Insights
IANS Faculty Break Down NIST’s Proposed New Password Guidelines
August 24, 2016 | Enterprise and IT Compliance Management
By Daniel Maloof, IANS Managing Editor
After recently recommending the phasing out of SMS-based two-factor authentication, the National Institute for Standards and Technology (NIST) has now released new guidelines (currently in a public preview period) for password security – and feedback from the infosec community has been all over the map.
Special Publication 800-63-3: Digital Authentication Guidelines, which is undergoing a two-week comment period on GitHub, offers a number of new guidelines for organizational password policies. These include:
- Minimum password length should be 8 characters, with a maximum of no less than 64
- All ASCII and UNICODE characters should be allowed
- Check against a list of “known-bad” passwords
- Remove knowledge-based authentication
- Stop practice of regular password expiration
- Don’t allow password hints
- Remove composition rules (i.e., “your password needs to contain at least one upper and lowercase character and one special character”), and instead focus on longer passwords
- Passwords need to be hashed, salted and stretched
Certainly, a number of these guidelines seem to fly in the face of what was once deemed conventional wisdom when it came to password security. And while it remains to be seen what changes are implemented during the comment period, a number of infosec experts have already offered their opinions on the new guidelines.
Let’s take a look at what some IANS Faculty have to say about NIST’s new password guidelines.
“I agree with most of the new guidelines," says IANS Faculty Dave Shackleford. "For instance, longer passwords are a great idea, and getting rid of mandatory complexity requirements is a smart move, too. Password hints and knowledge-based authentication need to go, too.
However, I have mixed feelings on the expiration recommendation. Given that we now know that many people use the same passwords all over the place, these accounts get compromised and used…forever? I think organizations need to be prudent with that one – require rotation for admins and people with any level of privilege, and increase account monitoring activities at the least.
I think requiring strong multifactor authentication will make these requirements much more reasonable. Also, NIST only recommends 8 characters as a minimum, and that should really be longer. If we’re doing away with complexity requirements (again, a good move), we should bump up the minimum length to 14 or so. All people have to do is string together a few words they can remember, as seen in this classic XKCD comic.
Personally, I would love to see organizations streamline their password programs using these guidelines – let’s get rid of the silly stuff that doesn’t work. Long passwords with multifactor authentication for everyone would be amazing, and then selectively require changes for some users (or use one-time passwords, even better!) As these recommendations are coming from NIST, undoubtedly many will pay attention and give them consideration. Many IANS clients can use this as a stepping stone to revising their password policies and authentication practices, and that’s probably a great thing. Passwords are here to stay, likely for the foreseeable future. We’d better learn to live with them, and do a better job of securing them.”
“Since I first started working in IT, I have always thought that it's ridiculous to require users to change passwords every 30 to 60 days," says IANS Faculty Kevin Beaver. "I think that's one of the fundamental areas where we went wrong that has led to many of the password management challenges we have today. The advice from NIST to not have password expirations without reason is going to create an uproar in the audit/compliance circles as that has (ridiculously) been the recommendation. It will all be for the better nonetheless.
I don't necessarily agree with eliminating knowledge-based authentication, in which the user picks from a list of questions, typically when resetting a password. I still think there is some merit to this approach. Granted, many people, including helpdesk/support personnel, have access to these questions and answers, which creates an opportunity for abuse. However, I still think we have bigger problems with security, like weak passwords that users are allowed to set, that must be resolved first.
It's a lofty goal to require a minimum length of 8+ character passwords. What we have here is a best practice versus reality mismatch. I can't tell you how many times I have tried to create strong passwords for web application user accounts as well as Windows domain user accounts and have been unable to because the developers of the application or administrators of the system didn't want to implement reasonable minimums for secure passwords.
Checking your passwords against a dictionary of known bad choices should never ever be up to the user. Don't get me wrong, everyone plays a unique role in security, but the moment you put security choices in the hands of users, all bets are off.
Weak passwords have been ailing security programs for decades. Knowing what we know and the standards that have been around years, it's sad that a government agency feels it has to establish standards and best industry practices around the subject. What does that say about the IT industry and the field of information security? What does it say about end users in general?
I think what we are seeing here is no different than what happens in other aspects of business, as well as in our personal lives regarding finance, health and the like: We know what needs to be done, yet we continue to see what we want to see and take the path of least resistance in order to inch ahead and get by, if we must. Instant gratification trumps long-term vision. This human element is precisely why we continue to have data breaches and why, regardless of any technical solutions or additional standards or regulations, we will continue to struggle with security issues.
Still, overall, this is a good opportunity for enterprises to rethink their approach to passwords. Many organizations like to follow the NIST standards, so I would advise those in charge of security to read this standard and pass it along up the food chain internally to, perhaps, get additional buy-in on information security initiatives.”
“Regarding password strength, this document is a swing and a miss," says IANS Faculty Mike Pinch. "There are many good points in here, but much of the wording utilized the phrase ‘should,’ which by its own admission is a suggestion.
There are much more robust password practices out there - albeit more complex - but what they’ve laid out is essentially an 8-character minimum with throttling of authentication attempts after too many failed attempts. This is not constructive and may be weaker than what many organizations are already doing. There are many other constructive thoughts in here, but they are preceded by the word ‘should,’ which indicates these are simply recommendations more than anything else. Missing is the concept of password changing, which the general security community has put less pressure on over the past several years, but is still considered a good practice.
Many more modern approaches have built adaptive password schemes based on entropy, allowing users to find passwords that are usable to them, but still secure.
On a more positive note, there are some good guidelines around the verifier side of the transaction, which requires salting and hashing (10k times!), as well as proper encryption of the transaction in a secure fashion. Far too many applications have suffered breaches from not following these best practices in development of their systems.
In summary, I wonder if NIST is trying to make password standards worse, so that they can push the much needed agenda of forcing two-factor authentication in more areas.”
| Tools & Templates
HIPAA Risk Assessment Template
| Executive Communications
CEO Credential Re-Use Exposes Businesses to Major Risk
Meet PCI Standards for Penetration Testing
| Tools & Templates
IANS Risk Register Tool