Why Relaxing Our Password Policies Might Actually Bolster User Safety
Recent guidance from NIST may seem counterintuitive.
Despite the publicity about breaches, ransomware, and the like, we're still using some pretty dumb passwords. Users typically aim for passwords that are easy to remember for their multiple logins, which they are asked to change frequently. Unfortunately, this has led to too many passwords that are far too easy to hack, causing one of security's biggest headaches.
SplashData posted its sixth annual most common passwords list in February, based on data taken from 5 million leaked emails over the year. Not surprisingly, variations of "password" and "123456" were ranked the top two most commonly used. Other highly used passwords include these:
football
princess
welcome
hottie
admin
The US National Institute for Standards and Technology (NIST) faced the problem head on in its recent recommendations, Special Publication 800-63-3: Digital Authentication Guidelines, released in June. Looking among many of NIST's recommendations, you'll spot a theme to relax on some policies — yes, relax, despite breaches being on the rise. I've highlighted a few of NIST's recommendations below, and provided my perspective as an identity and access management expert.
Remove Periodic Password Change Requirements
NIST specifically recommends having users create new passwords when they request to do so, or if there is evidence of a compromise. Say what?!
Yes, NIST believes that periodic password changes don't really prevent breaches. However, it also says that passwords should be at least eight characters in length. Ideally, they will be checked against passwords obtained from previous breaches, dictionary words, repetitive or sequential characters (for example, "aaaaaa" and "1234abcd"), and context-specific words, such as the name of the service, the username, and derivatives thereof.
I agree with NIST's recommendation here. Specifically, if an end user creates a sufficiently strong password, then why would you make him or her change it frequently? In fact, periodic password changes likely result in less-secure passwords, as frustrated users decide to opt for easy (and insecure) ones, reasoning that they'll have to change them sooner or later. The key here is to keep the password complex, otherwise we risk having insecure passwords for long periods of the time.
Usability Is Important
NIST points out that usability of authentication systems is paramount. If authentication methods aren't easy for end users, then they will work around complexity by writing down passwords and doing things like replacing vowels with numbers (such as "passw0rd" instead of "password"). Hackers have definitely figured this out already. Password policies and strategies have all been geared toward making passwords too complex to remember, and that has resulted in end users working around the complexity, in turn making passwords more insecure.
An executive once told me how he walked around at night flipping over keyboards and finding passwords written on sticky notes. And while old fashioned sticky notes may escape hackers' best efforts, digital documents can't.
Check Passwords Against a Dictionary of Compromised Password
Hackers typically will perform dictionary attacks against a target. They'll run through a list of passwords to see which one works. So one additional recommendation is to check a changed password against a database of known, compromised passwords. If the password has been compromised previously (such as "12345" or "StarWars") you can guess the hackers have that in their dictionary.
Personally, I think checking passwords against a dictionary of compromised passwords is the best practice to take to ensure that you're avoid using one that is commonly hacked.
Knowledge-Based Authentication Is Out
NIST recommends that knowledge-based authentication (KBA) be discontinued: "Memorized secret verifiers SHALL NOT permit the subscriber to store a hint that is accessible to an unauthenticated claimant. Verifiers SHALL NOT prompt subscribers to use specific types of information (e.g., "What was the name of your first pet?") when choosing memorized secrets."
I agree with this guidance as well. With the availability of Facebook and LinkedIn, it is increasingly easy for the bad guys to troll around for answers to things like "What high school did you go to?" or "What city did you meet your spouse in?" (This is especially true for celebrities, who must contend with the fact that all this information is publicly available, making them ridiculously easy to hack.) Questions such as "What's your mother's maiden name?" are also well out of favor now for the same reasons.
I strongly recommend that anyone who has KBA-type questions associated with a system go take a second look at those Q&As to ensure that 1) the questions cannot be answered by looking at your Facebook or LinkedIn profile, and 2) that you update your questions per my previous point and ensure that your answers are still accurate.
Passwords and Beyond
The upshot of this is that in its new guidelines related to authentication and authenticators, NIST has prioritized usability over complexity. NIST is putting the onus on the manufacturers of these systems to do a better job rather than putting it on the end user to remember complex password policies, which inevitably results in passwords being written down or stored in a Word document or Excel spreadsheet — like the infamous Sony breach, during which hackers simply searched through documents with "password" in their titles before stumbling on hundreds of valuable credentials.
Beyond changing these simple password policies, the right strategy when it comes to user authentication is one that is both adaptive and multifactor — one that accounts for human blunders and sophisticated hacks.
I'm looking forward to less rigor related to how often I have to change my password. IT, are you reading this?
Related Content:
Join Dark Reading LIVE for two days of practical cyber defense discussions. Learn from the industry’s most knowledgeable IT security experts. Check out the INsecurity agenda here.
About the Author
You May Also Like
DevSecOps/AWS
Oct 17, 2024Social Engineering: New Tricks, New Threats, New Defenses
Oct 23, 202410 Emerging Vulnerabilities Every Enterprise Should Know
Oct 30, 2024Simplify Data Security with Automation
Oct 31, 2024