Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Security Management

9/22/2017
02:37 PM
Yaron Zinar
Yaron Zinar
News Analysis-Security Now
50%
50%

NIST Redefines the Good Password

NIST has offered new guidelines for best practices in passwords.

What makes a secure password? The National Institute for Science and Technology (NIST) has released a new set of guidelines that will be required reading for those in government IT -- and highly recommended for everyone else. In general, the new guidelines push for longer passwords (eight characters minimum and support for up to 64 characters), while simultaneously relaxing rules for users in terms of what characters to use. All ASCII characters are to be allowed, but on the other hand, policies no longer require the use of special characters. Since in most cases, special characters add very little complexity to passwords with humans often simply substituting letters with similar symbols (e.g., "@" instead of "a"), it makes it very easily guessed by an attacker and really doesn't provide much additional benefit.

Next NIST adopted a simple but incredibly important shift in philosophy. Password security can't be evaluated in a vacuum, and what happens in the real world has to drive security decisions. For example, the complexity of a password won't do any good, if that password has been compromised in a breach. An attacker will crack that password almost instantly with a dictionary of known passwords. As a result, it's critical for organizations to evaluate their passwords based on dictionaries of common and breached passwords. Likewise, NIST did away with the recommendation for regularly resetting passwords. A password should be reset not based on some arbitrary timeframe, but rather based on real-world signs that it has been compromised.

Jim Fenton, a consultant for NIST, put together a very complete presentation covering all of the changes. The slides of his presentation can be viewed here, or the full video here:

Tips for implementing NIST's new guidelines
While all the new recommendations make sense, they do create some new work for security teams.

Here are the steps security teams will need to take to optimize your passwords based on NIST's best practices:

  1. Create and maintain a database of known compromised or bad passwords. How many passwords is enough? How often does it need to be updated? How often do you check?

 

  • Consider that the busy work of maintaining a large database of passwords and resetting compromised accounts can all be handled automatically without IT involvement. Automate these processes can be down without having to get IT involved or bother the security team.

 

 

  • Automatically maintain a massive database of compromised passwords and reveal any users or accounts using compromised credentials. Better yet, automate a response by either taking direct action such as quarantining the user, or by forcing the creation of a new password for the affected user. Conduct the all-important work of looking for account compromise or the use stolen credentials within your network.

 

 

  • Even the best password policy isn't going to stop phishing attacks, spyware, or malware from harvesting and reusing credentials or tokens from a compromised user. Look to a specialized provider to do the continuous heavy lifting by constantly analyzing the behavior of all users, accounts and devices in the network to identify signs of compromise. Once again, the responses to these behaviors can be fully automated.

 

 

  • Consider using a SSO (Single Sign-On) solution to manage access to external services and a password manager when SSO is not applicable. Using a password manager helps users choose more complex passwords that are unique for the particular service and in many cases help fight phishing attacks.

 

Getting beyond the password
While the latest NIST revisions are logical, practical, and welcomed, they are not a panacea. Passwords can only do so much on their own. Users will still need to remember multiple secret phrases, and will still get confused, and will still likely make small easy changes to compromised passwords (HumptyDumpty is cracked, why not HumptyDumpty1). And as mentioned above, passwords get stolen in a wide variety of ways. Even upwards of 30% of passwords that conform to Microsoft rules can be cracked in a short timeframe. The question for security teams is not how to establish a bullet-proof password policy, but rather how to bring additional context to situation and automate secure responses.

For example, if we notice that a user is beginning to behave irregularly, what is the appropriate response? His credential could be compromised and an attack may be in progress. On the other hand, we probably don't want to lock out our users every time they do something unusual. This is a natural fit for a second factor of authentication.


Want to learn more about the technology and business opportunities and challenges for the cable industry in the commercial services market? Join Light Reading in New York on November 30 for the 11th annual Future of Cable Business Services event. All cable operators and other service providers get in free.

If a user acts strangely, you will want to automatically challenge the user to verify identity and then take the appropriate action in response. Ideally you want to create policies for integrating multi-factor authentication into any application, and trigger those policies based on user, role, device being used, and a wide variety of other traits.

Get beyond these static rules to trigger responses based on the risk of the user's observed behavior. Lastly, you will want to take into account unusual behavior by the user, the use of an unmanaged device, or signs of a potential compromise.

In an ideal world, you let the password policy do its job without asking it to solve all things. We need good password policies, but we also have to monitor how our users and their credentials are being used live in our networks. Ideally those two things should work hand in hand.

Related posts:

— Yaron Zinar is senior security researcher at Preempt, pioneer of the industry's first Behavioral Firewall.

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
Commentary
What the FedEx Logo Taught Me About Cybersecurity
Matt Shea, Head of Federal @ MixMode,  6/4/2021
Edge-DRsplash-10-edge-articles
A View From Inside a Deception
Sara Peters, Senior Editor at Dark Reading,  6/2/2021
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
Current Issue
The State of Cybersecurity Incident Response
In this report learn how enterprises are building their incident response teams and processes, how they research potential compromises, how they respond to new breaches, and what tools and processes they use to remediate problems and improve their cyber defenses for the future.
Flash Poll
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2021-34682
PUBLISHED: 2021-06-12
Receita Federal IRPF 2021 1.7 allows a man-in-the-middle attack against the update feature.
CVE-2021-31811
PUBLISHED: 2021-06-12
In Apache PDFBox, a carefully crafted PDF file can trigger an OutOfMemory-Exception while loading the file. This issue affects Apache PDFBox version 2.0.23 and prior 2.0.x versions.
CVE-2021-31812
PUBLISHED: 2021-06-12
In Apache PDFBox, a carefully crafted PDF file can trigger an infinite loop while loading the file. This issue affects Apache PDFBox version 2.0.23 and prior 2.0.x versions.
CVE-2021-32552
PUBLISHED: 2021-06-12
It was discovered that read_file() in apport/hookutils.py would follow symbolic links or open FIFOs. When this function is used by the openjdk-16 package apport hooks, it could expose private data to other local users.
CVE-2021-32553
PUBLISHED: 2021-06-12
It was discovered that read_file() in apport/hookutils.py would follow symbolic links or open FIFOs. When this function is used by the openjdk-17 package apport hooks, it could expose private data to other local users.