Password Hash: It’s Okay to Inhale…
Monday, July 18, 2011
Contributed By: 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.
Direct Link: https://www.infosecisland.com/blogview/15202-Password-Hash-Its-Okay-to-Inhale.html