Network Security Policy Best Practices 101: Improving Password Policy
Follow network security policy best practices by using these tips to strengthen password requirements.
At the Microsoft NERD Center in Cambridge's Kendall Square (billed by nearby MIT as "the most innovative square mile on the planet"), the February meeting of the Boston Chapter of the National Information Security Group (NAISG) focused on the perennial thorn in the backside of information-security workers everywhere – the password. Network security policy best practices demand strong ones while simultaneously demanding that organizations look beyond the humble password, something not everyone is ready to do just yet.
"It's simple, it's trivial, it's so outdated, but it's the best we've got," said Patrick Hynds, founder of security consultancy DTS, of the humble password in his keynote address that evening, "Passwords: Keys to the Kingdom."
Password management is risk management. Hynds urged administrators to develop a strong and enforceable password policy – and went on to outline a number of useful tidbits and tricks for password management and security policies that the IT director or CISO can use to improve his or her organization's login security.
Network security policy best practices require more than just a password
Network security policy best practices dictate that organizations use multiple authentication methods to control access to corporate resources. "Allow or require a multi-factor [identification protocol]," insisted Hynds. "Multiple factors [make it] harder for the attacker."
In conjunction with passwords ("Something you know"), Hynds urged participants to use tokens or fobs ("Something you have"); biometric scans of fingerprints, eyes, or faces ("Something you are,") and/or even the emerging identity factor of "Something you do" – such as handwriting matching, voice recognition, and typing-pattern analytics.
"Having a password and a PIN is not two-factor authentication," Hynds took care to emphasize. "It's two-element authentication."
While Hynds concedes that no single factor or even combination thereof is foolproof (noting that even biometrics are not infallible), there is little excuse to not implement multi-factor authentication at the enterprise level.
"The gaming industry allows it!" Hynds highlighted. "My World of Warcraft account is more secure than most of your banks."
Network security policy best practices demand secure authentication points
Brute-force attacks – i.e., where hackers simply attempt to guess passwords, usually aided by computer automation and a "dictionary" list of words and phrases – are one of IT's biggest worries when it comes to login security. Accordingly, IT administrators committed to network security policy best practices must batten down the hatches to minimize exposure of user information.
One often overlooked security hole at the login screen is when the server exposes excessive information – such as by giving a notice after a failed login attempt that the password was incorrect.
"Oh, that password was incorrect," gibed Hynds. "Well, thanks, now I know that username is correct."
Perhaps more pressing, however, is the need for protection against automation. Hynds noted that for under $2,000, anyone could buy "a good GPU" capable of approximately five to ten billion login attempts per second.
"I shudder when I see an authentication point that will allow a user dozens [of login attempts] per second," Hynds said. "Humans can't do that. They're allowing automation."
One defense against this automation is a complete lockout of the user after a certain number of successive login failures. This is one of the more commonly followed network security policy best practices, and in some cases it may even be required (Massachusetts regulations, for example, require that security systems of entities storing PII of Massachusetts residents should "to the extent technically feasible, block access to user identification after multiple unsuccessful attempts to gain access or the limitation placed on access for the particular system"). Sometimes user lockout goes a step further, completely wiping all data after a given number of successive unsuccessful attempts.
According to Hynds, however, full lockouts can be hazardous, especially after a relatively small number of failed logins, because they can be turned against the organization as a denial-of-service attack.
Instead, Hynds suggested that logins be delayed after each failure and that further attempts be delayed exponentially with each successive failure. This would effectively mitigate the risk of automated brute-force attempts because it would take days to make even a few dozen guesses.
Of course, the user's password should be strong enough to withstand at least initial brute-force standbys and basic dictionary-based brute-force attempts. Hynds recommends that, at minimum, the IT department's password policy should require that a user's password be able to withstand a full minute of automated brute-forcing.
Consider the following possible passwords that Hynds offered as examples in his presentation:
"None of these are secure passwords when there's a dictionary and brute force of play," said Hynds. "Your password should not be findable in a dictionary."
Hynds went on to note that password dictionaries, which can include more than one billion entries, include words, slang, titles, places, musical group names, and variations of those and other words.
"[H]ackers…know about [using] the at sign ["@"] for A's and dollar signs ["$"] for S's," noted Hynds.
This raises a question: What might a secure password look like?
Network security policy best practices emphasize password length over depth
Hynds presented his audience with a hypothetical: If you had a one-character password that could only use lowercase letters, how easy would that password be to guess?
The question, of course, was rhetorical, but it set up Hynd's next point nicely when he asked the group how to make that password harder to guess. Obviously, one could add characters to the character set (uppercase letters, numbers, nonalphanumerics, etc.), but adding more characters to the length of the password offers, in the long run, longer odds on the ability to correctly guess the password. Shorter passwords, argued Hynds, are easier to hack, and users with shorter passwords are at greater risk than users with much longer ones. Network security policy best practices therefore prioritize password length over password complexity.
"Low-hanging fruit gets hacked," said Hynds, who went on to relate the old "I don't have to outrun the bear…" joke. "This is a big problem."
Accordingly, the first password-management step for an IT administrator is to set an appropriate minimum length for passwords. Hynds suggests that a good password will be a minimum of 16 mixed characters long. The next steps entail ensuring not only that a user can register a much lengthier password (Hynds goes so far as to advise people that if their online banking account won't allow for passwords longer than 16 characters that they should switch banks), but also that the login fields will accept such a lengthy password.
"There are some places where you can set a long password, but you just can't use it...because the length of the field is different," Hynds pointed out. "You set a 20-character password; now you gotta call support to log in. So bad design is a big part of [bad security.]"
The other obstacle in the way of long-password use is the user him- or herself. Users are notoriously lazy or forgetful. This is especially the case in IT environments, where network security policy best practices often compel them to change their passwords as often as every three months, if not even more often.
"Companies like Bank of America have staffs of people who have to change passwords on a daily basis," noted Hynds.
Hynds, thereby, suggests a peace offering between IT and users in the name of security, urging IT administrators to set the following policy for their users: "If your password is…greater than 30 characters, you never have to change it again."
Users can also be encouraged to use longer, more secure passwords in the form of a more memorable and more user-friendly passphrase.
"A passphrase [is] just a long password," said Hynds. "It's very easy for a touch typist to type, typically."
And, according to Hynds, a long passphrase such as "ShouldIStayOrShouldIGoNow" is stronger than a short password – even if the shorter password has more character depth (such as "P@$$W0RD!").
Lucien Labreque, President of NAISG, agreed, telling that night's participants, "The passphrase is the trick to use to get users to make the password longer."
So just how long a password is long enough for Hynds himself?
"My password on my domain is 54 characters long," said Hynds. "Why? Because I have hackers working for me, and I was sick of them telling me my password all the time."
After some laughter from the group, Hynds emphatically clarified, "I'm not kidding."
Joe Stanganelli, Principal of Beacon Hill Law, is a Boston-based attorney, business consultant, writer, speaker, and bridge player. Follow him on Twitter at @JoeStanganelli.