Password Hash: It's Okay to Inhale...

Monday, July 18, 2011

Vulcan Mindm3ld

As security experts, we know the importance of password hashing. Unfortunately, recently compromised systems leads me to believe that their designers, implementers, and management teams which accepted these systems were exposed to too much tetrahydrocannabinol.

In a recent discussion with some friends in the information technology industry, I was shocked when they didn't understand what I meant by storing passwords as “plain text” instead of a hash.

I had flashbacks of when I was responsible for some production systems many years earlier. Because I was the guy “facing” the auditors, I wanted to get some insight on a new application we were expecting. I had asked a developer how the web application stored user account passwords.

I asked him, “Does it use MD5 or SHA?” and he responded “No. It wasn't necessary.” He said, “since we must secure shell into the box over an encrypted channel and you must have a password to get into the database then he added it wasn't worth the performance hit to hash the passwords.”

Of course, I was outraged and began to complain to anyone who would listen. Soon, I was labeled as a nosy systems guy who didn't know what I was talking about. Some of the developers insisted I wasn't even qualified to discuss such matters. Nonetheless, I persisted and got my way – but not without a fight.

I explained to some of the managers that a password table is like a “spreadsheet” with rows and columns (Yeah, I had to get that basic). One column contains a user name and the adjacent column is the password. If the database is compromised, this table can be extracted and the attackers will have a list of user names and passwords.

Once they grasped this concept, I explained hashed passwords. If we take the plain text password BEFORE it is entered into the table, we can use a cryptographic function on the plain text in order to store a large hexadecimal string.

The important thing here is that it is not the plain text password which is stored in the database. For example, two highly complex passwords (insert sarcasm) chosen by the finest executives might be “apples” and “applesoranges”:

“apples” – 76c2436b593f27aa073f0b2404531b8de04a6ae7

“applesoranges” – 1748298913aca6c373b52958ec224508a790e5b6

When a user logs into the system, the cryptographic function is called using the password they've provided and the result is compared to the value stored in the database for that user. If it does not match, the user is not authenticated and access is denied.

Once they understood the technical aspects of the problem, I assumed they would understand how risky the design was. In the end, it wasn't my over-simplified explanations and their understanding of the risk, the design was changed because of their fear of not getting their system approved for operations. It is appalling to think that they would have implemented it despite the risk.

I had this encounter several years ago but this kind of implementation continues. The recent IRC Federal and HBGary SQL injection vulnerabilities allowed attackers access to a username/password table stored in the database. IRC Federal's “experts” simply stored unencrypted passwords while HBGary's “expert” third-party developers implemented unsalted, non-iterated MD5.

This simple use of MD5 is highly susceptible to dictionary attacks and brute-force attacks. Think of two tables: one, a list of common words and their pre-computed hash. The second is the compromised table. 

To “crack” this password, the stored hash is simply checked against many common dictionary files. A brute-force attack is significantly slower depending on the complexity (e.g., character composition, length) of the user's chosen password . Of course, attackers can use a cross between a dictionary attack and a brute-force attack called rainbow tables (see RainbowCrack Project for more information).

To defend against these kinds of attacks it is recommended to use “salt” when computing the hash or even use Password-Based Key Derivation Function (PBKDF2) in lieu of iterative hashing.

I am not going to discuss the merits of different algorithms, salting, or other techniques in this post. Instead, I would much rather see interested parties ask developers, implementers, and maintainers the right questions. How are passwords stored? What have we done to protect against SQL injection?

Finally, to compound the problem some of HBGary's executives used very, very weak passwords which were easily broken. Both IRC Federal and HBGary executives used the same password on many of their other information technology resources including their own email accounts. You might as well have invited the attackers over for cocktails and hors d'oeuvre.

Simple passwords and reusing said passwords has been part of every security professional's mantra for years. Shame on them.
Possibly Related Articles:
Network Access Control
Information Security
SQl Injection Passwords Network Access Control Hashes hackers HBGary Federal PBKDF2 Rainbow Tables
Post Rating I Like this!
Josh Stemp This is very similar to what we were commenting back and forth about a couple of days ago-Essential Security Measures. Using complex passwords is the user's responsibility and it is the developer or infosec pro's responsibility to supplement the user's effort by hashing their passwords. If the infosec pro doesn't hash the passwords, that's an even lesser reason why the user should even try to use complex passwords.

Great article! I feel that all infosec pros should know the ins and outs of the security of their organization's applications of choice.
Vulcan Mindm3ld Thanks @Josh... I searched for the "Essential Secure Measures" article but I could find it. I'd love to read it if you don't mind sharing a link.

Josh Stemp Nah, the two of us were commenting back and forth a couple of days ago on the "We Are InfoSec Professionals... Who The Hell Are You" article.
Vulcan Mindm3ld Yes! I am familiar with that article and the comments. Thanks.
The views expressed in this post are the opinions of the Infosec Island member that posted this content. Infosec Island is not responsible for the content or messaging of this post.

Unauthorized reproduction of this article (in part or in whole) is prohibited without the express written permission of Infosec Island and the Infosec Island member that posted this content--this includes using our RSS feed for any purpose other than personal use.