Everything we've known as true about password security really needs to be revisited based on current technology, trends in password cracking, and a better understanding of social engineering and human psychology in general.
For years we have been told that the more complex the password was the more secure it was. We enforced this methodology on our poor users because we "knew" what was best to protect our precious network and its data. But then we turned around and complained almost daily about some user who wrote his or her password down as to not forget it and have to "bother" IT once again.
It has become a standing joke, yet we continue to do nothing to fix the problem. We just laugh and repeat ourselves about the sanctity of the password and continue on our merry way, oblivious to the truth that the user really doesn't care about our beliefs, and as soon as we walk away they retrieve the sticky note with their password from the garbage can and put it in their top drawer, which is an improvement at least from having it on the monitor.
Old machinesOnly a few short decades ago, we were taught that "P@ssW0rd" was more secure than "password" and that we should always use at least three of the four secure methods in our passwords: lowercase, uppercase, digits, and special symbols. Then we changed it to insisting that all four be used in a password to "guarantee" that it was secure. That hasn't really changed since, but it is time it does.
Back then computers simply weren't strong enough to run through all the possibilities, and we sat complacent that no computer would be able to run all 895 combinations in a timely manner, and, for the most part, that was true. That was where most of our "password security training" ended — why would we need to know any more than that? Why would we need to know that Windows 95’s password hashing was essentially nonexistent, until it was fixed in the second release? Or that LANMAN truncates all password hashes to fourteen characters, case insensitive, and doesn't salt the hash?
Thankfully, NTLM is far more secure — salts its hashes, and has removed all the shortcomings of LM. So, we’re safe now, right? Let me ask you this, have you turned off LM on your servers that are 2003 and earlier? No? Then hopefully all your passwords are at least 15 characters long, because that’s the only way to ensure that only the NTLM hash is being saved.
New machinesLet’s return to the issue of computing strength. As was mentioned, a few decades ago PCs simply weren't robust enough to handle cracking of passwords that required brute force attacks. However, processors have grown in power, yet we haven’t really revisited the strength of those old eight character passwords that we've been relying on all these years. So let’s do that.
Almost three years ago, the British website Lockdown.co.uk posted the stats for how long it would take to hack various passwords based on both complexity and length. And for the most part it should impart to the reader that length is indeed far more important than complexity. It’s fairly obvious as one reads down the tables that the longer the password is the longer it takes to crack. However, that table is reflecting computing power and capabilities from three years ago.
Now, consider this information from the Georgia Tech Research Institute that explains that GPUs are now capable of cracking passwords in minutes that used to take days. This gets scarier still. Consider that the goal for the cracker is to find a valid password in a reasonable amount of time, which for the cracker could be a day or two, or even longer if there is profit and/or fame to be had. Obviously, the cracker is going to want to use the power of GPUs to get these faster turnaround times, so just how fast can they go given a reasonable amount of money and/or equipment? How does 33.1 billion passwords per second sound? That was achieved at the end of 2010, and if that cracker has the money available, they can even hire a cloud service that delivers up to four teraflops of single-precision peak performance and 515 gigaflops of double-precision performance using GPU computing power. By now this should have you seriously considering the minimum lengths of your passwords.
The first part of the cracker’s strategy is the software at his or her disposal. The software is focusing more and more on exploiting the power of the GPU, and these programs are surpassing the CPU based cracking tools that we are most familiar with.
As this blog post points out, GPU cracking tools are now shortening cracking times down to minutes, and those tools are just going to get more efficient as time goes on So what are we to do? Obviously make passwords longer, right? But what about our users? If they wrote passwords down before, they are definitely going to do that if the passwords are long.
Again, that isn't necessarily true if we take the proper approach — more on that in a bit. The second part of the cracker’s strategy is the requirement that they actually have access to our network. This means they need to gain access via a compromised computer or directly to the network by getting their own computer connected to it. So, since the password is securely stored via NTLM hash on our Windows server, or any of the various UNIX-based hashes on a UNIX box, that shouldn't be a problem, right? Perhaps, but are you positive that all your services — specifically web services — are secure and that there are no unpatched exploits? Then it is likely better than perhaps, but what about your weakest link?
Service passwordsSince services were just mentioned, we would do well to ensure that the passwords that we use for our services are also following the methods presented here. Remember that services typically have just as many rights as the admin, and in some cases, more. Because services passwords are rarely used once entered, consider making them as long and complex as possible. This would be especially true for Internet-facing services.
The humansThe final piece to our security is also the one that we have very little control over — the humans. It doesn’t matter if they are an end user, a company executive, or even a member of the IT staff. We are all fallible. This is where the cracker strikes next or, more often than not, first.
Social engineering is of very real and serious importance to most crackers. It often requires the least amount of effort and resources and can provide the best access to the resources they are trying to steal. A simple call to a middle manager mentioning an executive’s name (both of whose identities were discovered via a business card raffle at the local deli) can be used to get software installed. Or, by putting on a contractor’s shirt, one can gain access to a business to hunt for displayed passwords and user names, or even worse, install software on users’ computers or bring in a mobile device to gain access. Even getting hired on as a night janitor can net the cracker all the information and access he or she needs, and often this also gives them access without the watchful eyes of the employees. More subtle approaches come in the form of routine sales and marketing calls or surveys — we seem almost eager to give perfect strangers all sorts of information that could be used to guess our passwords. That is if we use standard methods of determining our passwords. Thankfully, we can take some rather simple steps to deal with these issues.
Talk to your usersExplain the things mentioned above and what to watch for. Make sure that you — the IT professional — are not viewed as the enemy but rather as an important asset to the company that serves the user as a resource and as a helpful watchdog to the data that keeps the company running — and thus keeps the user employed.
Train users on how to make a secure password from their perspectiveVery few users, if any, are going to comply with your wish to make their passwords filled with symbols and numbers because they are going to do the very thing you tell them not to do, which is write it down. As we saw above, a long password, or passphrase — the term we really should start using — is far superior to a short complex one.
Empower your users to create long passphrasesWhy not tell them to use a sentence for their passphrase? Compare the following: "Wl12$zP39_Ix" and "This 1 password gets me to my lions, tigers, and bears!" Both have all the complexity elements, but the first is 12 characters that are so complex that even writing it down may not make it obvious, and the second is 55 characters long and is easy to remember for several reasons.
Pad the passphraseTake it a step further and explain how the strategy should be something personal to the user that they come up with and mention "padding" passphrases, which might be even easier than sentences. Padding simply means adding characters to the password. This can be as simple as adding the last four numbers of the social security number to the end of the password or taking their address and putting half at the beginning and the end of the password. This strategy allows your users to still use their completely unsecure passwords that can be found in milliseconds with a dictionary attack and turn them into passwords that will require a brute force attack, and considerable time. For example, "22 Main-password-Street." Note the space between the numbers and name and that it is 23 characters long. We don’t want the passwords to be written down, so don’t force your users to rely on their memory for a password that means nothing to them — it won’t happen.
If your users aren't sure about their password, have them visit this site and try it out, but explain to them that this is not a "password strength meter" as the text on the page points out.
Don’t be too hard on usersFinally, remember that your users are just that — users. Few of them care about the intricacies of the things that happen behind the IT curtain, and they really only want to get their job done with as few complications as possible. So, make all this security stuff fun for them and remove some of the insane constraints we put on them, and they’ll be much more willing to comply with your policies — and not be the weakest link in your security.
If you need more proof weak passwords are still subverting IT security, see this post in the Spiceworks Community: http://community.spiceworks.com/topic/218528-weak-passwords-still-subvert-it-security. How do you work with users to ensure they’re using strong passwords or passphrases?