How to be safe from password encryption exploits

When warning about the threats of web page strikes like SQL injection and remote file addition, we frequently speak about how these breaches can expose “sensitive information.” What type of delicate data? Well, lots of kinds, such as private information about customers or privileged information like internal business records. But the type of delicate information often targeted in web page strikes are user account informations. Briefly: passwords.

Hash the password

Of course a reputable organization would never store user passwords on their servers unencrypted. Unfortunately that is not true for the 450,000 users whose Yahoo Voice usernames and passwords were leaked earlier this year. In this attack, hackers have used SQL injection in order to dump the passwords from a database table.

This kind of breach was possible due to three critical security failures found at Yahoo:

• Being vulnerable to an SQLi attack for the beginning. A good sanitization of user input might have prevented this.
• Storing the passwords in PLAINTEXT format on the server – just like asking hackers to come in.
• Storing the passwords on the server at all.

Although this matter is about “password encryption,” in the real life it’s not wise to store user passwords at all, whether in plaintext or encrypted by a fancy algorithm. When a user doesn’t remember his password, your website should not be able to find it — just because it does not exist in a retrievable pattern.

After an account password is generated, either it’s from the user or the system, the best method is to store only a hash of this password. A hash represents a value calculated from the content of the password, and it can only be generated in one way. Thus a hash can be created from a password, but not the other way around.

But that is not all, because hackers also know that all hashes are not equally created.

Obfuscation does not represent security

Let’s say a hacker has managed to get a table of password hashes from your database. You might say “no harm no foul” because the hashes cannot be cracked and reveal the passwords.

A lot of password security systems are created to use either the MD5 or SHA1 algorithm to generate the hashes. A hacker that wants to find something from these hashes has a couple of alternatives:

Brute force attack. Using a brute force attack, the hacker tries to crack the passwords by trial and error. If he has identified that the hashes are generated using SHA1 for example, he will run a list of candidate passwords through an SHA1 hash and compare the results to the thieved data. If he founds a match, the hacker has just revealed one password.

Brute force attacks can depend on “dictionary” files to create candidate passwords, because a lot of users generate their passwords using common words. Combining the words with numbers and symbols can result in the success of a brute force attack. Complex passwords with medium to long length are more difficult to be cracked by brute force and may require more processing power (and patience) than the hacker may want (or have) to use.

Rainbow tables. Hackers with an interest in efficiency have embraced a tool called the rainbow table. This table is a pre-computed dataset for a given hash algorithm (such as MD5), containing millions of permutations. Although a rainbow table can be very large in data size, it can also significantly reduce computing time to find a string of characters which maps to a given hash. In the wrong hands, rainbow tables are a dangerously effective tool.

There are numerous resources online a hacker can use to look up hashes in pre-existing rainbow tables. In short, even hashing of passwords is not secure enough.

Dash of Salt

One weakness of simple hashes is that they are predictable. For example, the MD5 hash of the password “mydogFido” is 0529ee331f4491e7e61894f32edb1112. If your system has a dozen users who all used this same password, they will have identical hashes in the database. A hacker who decrypts this password by brute force or rainbow tables has now compromised all dozen accounts.

In the real world this problem is even worse because too many users choose simple phrases like “password” and “1234” even when advised to create longer and more complex passwords. This is exactly the breach that struck LinkedIn in June of this year.

A salt is data appended to the password before it is hashed. Using salts, your system can generate unique hashes for every user regardless of how weak their chosen passwords actually are.

Your salt needs to be data which adheres to a formula that is unknown to the hackers. For example, a salt might consist of random number+Unix time of user account creation. Another possible salt formula is to employ the username modified through a predictable transformation (such as repeated twice).

There are countless ways to generate a strong salt, but the point is that once a good salt is added to the user’s chosen password and then hashed, that hash will be unique. Because each hash is the result of a different salt, even identical passwords will have different hashes. This makes it impossible to effectively use a rainbow table attack against your password database.

Rise of the GPU

For years, salting hashes has been the best practice to defend against password encryption attacks. But this is changing because of graphics cards.

Even a salted hash can be decoded given enough time and processing power to brute force every possible combination. Modern graphics cards, optimized to perform massively complex mathematical functions to produce sophisticated visual effects in video games, now feature extremely powerful processors called GPUs.

Consider this sobering metric: Cracking a password hash that would take 90 minutes on a modern CPU could take as little as 4 seconds on a modern GPU. Sophisticated hackers can amass a cluster of GPUs working in parallel. They can now burn through even the best salted hashes in a fraction of the time compared to just a couple of years ago.

Today’s best defense is to increase the “cost” of processing time. The best practice to date is to adopt the algorithm called bcrypt to generate salted hashes in place of the traditional algorithms like MD5, SHA-1 and SHA-2.

Bcrypt allows you to create very costly hashes – that is, they take a long time to calculate. Measured even in an extra few hundred milliseconds, the processing cost incurred when a user creates an account or logs in is not significant because these events do not occur millions of times a second (unless you are Google). Yet a brute force attack using a GPU will be significantly slower, demanding that the hackers can afford the time and resources to compromise your database.

While it is never possible to guarantee against an encryption breach, every security measure reduces your vulnerability and increases the demands on the attacker.