Password Policy Gets a Reset
In a recent blog, we discussed how attackers typically follow the path of least resistance. In enterprises, this almost always involves seeking out weak passwords. Data from Verizon’s Data Breach investigation Report certainly bears this out, where they found that nearly 2/3s of breaches involved the use of weak, default, or stolen credentials. As much as the industry likes to focus on nation-state attackers and obscure 0-days, the fact remains that most battles are lost due to a lack of basic password hygiene in the network.
And while password security may seem like old hat, NIST has embarked on a major re-examination of its recommendations concerning passwords. In this blog, we will take a quick look at what has changed, ways that you can put NIST’s new recommendations in practice, and how we can complement password policies with additional context and controls.
Getting to Know the New Best Practices
First, let’s take a quick look at how NIST recommendations have changed. We won’t cover all of the changes, but Jim Fenton, a consultant for NIST, put together a very complete presentation covering all of the changes. You can view the slides of his presentation here or the full video here.
In general, the new guidelines push for longer passwords (8 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 most humans simply substitute special characters for a letter (e.g. “@” instead of “a”), the substitution can be easily guessed by an attacker and really didn’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 time frame, but rather based on real-world signs that it has been compromised.
Putting the Changes to Work
While all the new recommendations make sense, they do create some new work for security teams. The first of which is the need to create and maintain a database of known compromised or bad passwords. How many passwords should be enough? How often does it need to be updated? How often do you check? Preempt addresses these questions and automates the solution for a security team. The solution automatically maintains a massive database of compromised passwords and reveals any users or accounts using compromised credentials. Better still, you can customize it to include your own keywords that will automatically create variations of that word and add them to the dictionary. The solution can also automate response to a weak password by either taking direct action such as quarantining the user or by forcing the creation of a new password for the affected user. The important point is that the busy work of maintaining a large database of passwords and resetting compromised accounts can all be handled automatically without IT ever getting involved.
Next, Preempt does the all-important work of looking for account compromise or the use of 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. Once again, Preempt does the continuous heavy lifting by constantly analyzing the behavior of all users, accounts, and devices in the network to identify signs of compromise or breach. Once again, the responses to these behaviors can be fully automated. Which, brings us to our next point.
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 the 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 the second factor of authentication. If a user acts strangely, we can automatically challenge the user to verify identity and then take the appropriate action in response. Preempt makes it easy to create policies for integrating multi-factor authentication into any application, and trigger those policies based on user, role, the device being used, and a wide variety of other traits. Preempt also goes beyond these static rules to trigger responses based on the risk of the user’s observed behavior. This is where we can take into account unusual behavior by the user, the use of an unmanaged device, or signs of a potential compromise.
In this way, we can 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 and automate the process so that security teams can focus on more important tasks. Ideally, those two things should work hand in hand.
Posted by Wade Williamson on September 22, 2017 2:26 AM