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
COVID-19: Latest Security News & Commentary
Dark Reading Staff 7/9/2020
Omdia Research Launches Page on Dark Reading
Tim Wilson, Editor in Chief, Dark Reading 7/9/2020
4 Security Tips as the July 15 Tax-Day Extension Draws Near
Shane Buckley, President & Chief Operating Officer, Gigamon,  7/10/2020
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
Current Issue
Special Report: Computing's New Normal, a Dark Reading Perspective
This special report examines how IT security organizations have adapted to the "new normal" of computing and what the long-term effects will be. Read it and get a unique set of perspectives on issues ranging from new threats & vulnerabilities as a result of remote working to how enterprise security strategy will be affected long term.
Flash Poll
The Threat from the Internetand What Your Organization Can Do About It
The Threat from the Internetand What Your Organization Can Do About It
This report describes some of the latest attacks and threats emanating from the Internet, as well as advice and tips on how your organization can mitigate those threats before they affect your business. Download it today!
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2020-15105
PUBLISHED: 2020-07-10
Django Two-Factor Authentication before 1.12, stores the user's password in clear text in the user session (base64-encoded). The password is stored in the session when the user submits their username and password, and is removed once they complete authentication by entering a two-factor authenticati...
CVE-2020-11061
PUBLISHED: 2020-07-10
In Bareos Director less than or equal to 16.2.10, 17.2.9, 18.2.8, and 19.2.7, a heap overflow allows a malicious client to corrupt the director's memory via oversized digest strings sent during initialization of a verify job. Disabling verify jobs mitigates the problem. This issue is also patched in...
CVE-2020-4042
PUBLISHED: 2020-07-10
Bareos before version 19.2.8 and earlier allows a malicious client to communicate with the director without knowledge of the shared secret if the director allows client initiated connection and connects to the client itself. The malicious client can replay the Bareos director's cram-md5 challenge to...
CVE-2020-11081
PUBLISHED: 2020-07-10
osquery before version 4.4.0 enables a priviledge escalation vulnerability. If a Window system is configured with a PATH that contains a user-writable directory then a local user may write a zlib1.dll DLL, which osquery will attempt to load. Since osquery runs with elevated privileges this enables l...
CVE-2020-6114
PUBLISHED: 2020-07-10
An exploitable SQL injection vulnerability exists in the Admin Reports functionality of Glacies IceHRM v26.6.0.OS (Commit bb274de1751ffb9d09482fd2538f9950a94c510a) . A specially crafted HTTP request can cause SQL injection. An attacker can make an authenticated HTTP request to trigger this vulnerabi...