Do passwords matter?

You don’t have to look very hard to find an article discussing password breaches. Recently, there was a lot of buzz around LinkedIn, Last.fm, and eHarmony, three very large sites suffering from passwords being leaked to the public. This is not a new phenomenon (earlier this year everyone was all up in arms about the Zappos password breach), but one that continues to garner attention in the media.

However, what most journalists are saying about password breaches is likely different from what I am about to tell you – it simply does not matter how strong your password is, how it is encrypted when stored by the provider, or how the transport layer is encrypted (e.g., SSL). Here’s why:

How it’s encrypted matters, but no one does it right
Many websites today, primarily for performance reasons, are using traditional one-way hashing algorithms to store your passwords (such as MD5 or SHA1). This means you give the website a password, it computes a cryptographic hash and stores it in a database of some kind. The plaintext password should never be written to disk. The next time you login, the website computes the hash in the same manner and compares it to the value stored in the database.

This is all well and good, until someone obtains a copy of the password hashes. Obtaining the hashes, without any other protections, such as password salting, two or more users with the same password will have the same hash value. This allows attackers to generate very large databases of already-hashed passwords and make a comparison. Hardware on graphics processing units (GPU) can help accelerate the process.

There are also websites that will provide hash-cracking services (submit the hash to a website and get the cleartext password in return). Several of these sites also use “Rainbow Tables,” a form of lookup tables which takes a bit longer, but allows for smaller tables. A “salt’ will help slow down this process, a little. Salts are a random string appended to the password such that user’s passwords are different.

However, sometimes developers implement salts incorrectly, and use the same salt for each user or store the salt where attackers can obtain it (or calculate it). Even if salts are implemented correctly, the processing power of GPUs can be used to crack the salted password hashes in more time, using even larger pre-computed password dictionaries than ones without a salt. What does all this mean? Likely, at least a few websites (internal to your organization or external) are storing your password using a hash that can be reversed in a relatively short timeframe, depending on the hash used and computing power of the attacker.

“Password complexity matters not”
First, let us take a look at some of the password policies on many of the websites on the Internet. Many do not even let you set a strong password, keeping you within seemingly arbitrary limits of length, and enforcing ridiculous complexity characteristics, such as making you use a least one number, one special character, and one uppercase letter. What happens in this case, with a website requiring a minimum 5-character password, is the user ends up with a password of !234F. When passwords such as this are cracked, it’s fairly easy (Letters, numbers and symbols have about 10 billion possible combinations, and attackers can exceed 1 billion passwords per second).

The attacker can tune the password cracker to the site’s password policy, then build a dictionary containing only passwords that meet the policy. Taking into consideration that most people will choose the smallest possible password length, and building in common passwords and phrases, the rate of success is very high.

The bottom line is if an attacker is using modern password-cracking hardware, complexity matters little. What does matter is the length of your password, which can help to increase the time it would take for an attacker to crack your password. Again, many websites limit the length and defeat one of the only protections you have in this scenario.

Transport layer security stinks
Let’s say you have a 20-character password, and the website is using a strong hashing algorithm with a properly-implemented salt. The one common condition that will occur for all users is you must submit your cleartext password to the website. Sometimes this does not even occur over SSL, as some developers get lazy, or have an HTTP and HTTPS version of the site, but do not enforce the SSL version upon login.

Let us even say that login must be done over SSL; we’ve recently seen where root CA certificates were compromised and how SSL MiTM attacks can be successful (even against folks that should know better). So, rather than spend a whole bunch of time trying to break into the server hosting the target website, steal the hashes and then try to crack them, an attacker will simply attack the users and the transport protocol.

Passwords are easily obtained or not needed
In certain circumstances, such as with older Windows systems using LM (LANMAN Hashes), the cleartext password is not required. To gain access to systems you can simply re-play the hash (for example, Nessus supports this “feature” and allows you to enter LM or NTLM hashes as a password and performs a “pass-the-hash” technique to the target systems). If a password is required to gain unauthorized access to a system or application, software or hardware keystroke loggers are a great way to capture the password as its being typed. In addition, if an attacker has access to your system, it’s likely that your passwords are stored somewhere accessible, such as in the Registry on Windows or in Keychain on Mac OS X.

What does matter?

• Security Architecture – Most password breaches are a result of an attack against the website and/or database, and frequently it occurs as a result of SQL injection. The solution is to implement a resilient security architecture which includes strong change controls, system hardening, event logging and monitoring, and, of course, vulnerability management. Couple this with a solid incident response program, and as the provider of services, you will be much harder target than those with a weak security architecture.
• Development & Quality Assurance Programs – Many of the problems with either the attackers gaining access to sensitive information or loose security surrounding the data itself, come down to decisions made by developers. Ease of development and speed often take priority over security, until such time there is a security breach. Educating developers, and everyone in the process including QA, about what it means to have a secure product before there is a breach, is extremely important.
• A Password Strategy – As an end user, or organization looking to implement a password policy, look for techniques that work. Despite what others have said, or what you hear in the press, there are really two strategies that work. First, set longer passwords; in general, greater than 12 characters. This greatly decreases the chances of your password being guessed, brute forced, or cracked. Second, don’t use the same password for everything. I know, age-old advice, but it couldn’t be more relevant today. There are several software programs to help you manage all of the passwords you have to remember on a daily basis (which is by all accounts A LOT).

Conclusion
When your organizations uses or implements software that requires a user account and password, keep in mind that security goes beyond a simple MD5 hash and password requirements. It begins with either writing or obtaining an application whose developers understand security and implemented it correctly. Your security strategy then transitions to operations, where system hardening, configuration auditing, and vulnerability management are key components to success. The responsibility finally lies with the end user, and making certain they are following rules and guidelines that both make sense and help protect their information.