Understanding Hash Functions and Keeping Passwords Safe

From time to time, servers and databases are stolen or compromised. With this in mind, it is important to ensure that some crucial user data, such as passwords, can not be recovered. Today, we are going to learn the basics behind hashing and what it takes to protect passwords in your web applications.

1. Disclaimer
Cryptology is a sufficiently complicated subject, and I am by no means an expert. There is constant research happening in this area, in many universities and security agencies.
In this article, I will try to keep things as simple as possible, while presenting to you a reasonably secure method of storing passwords in a web application.

2. What Does “Hashing” Do?

This is accomplished by using a one-way hash function. “One-way” means that it is very difficult (or practically impossible) to reverse it.
A common example of a hash function is md5()

, which is quite popular in many different languages and systems.

With md5(), the result will always be a 32 character long string. But, it contains only hexadecimal characters; technically it can also be represented as a 128-bit (16 byte) integer. You may md5() much longer strings and data, and you will still end up with a hash of this length. This fact alone might give you a hint as to why this is considered a “one-way” function.

3. Using a Hash Function for Storing Passwords
The usual process during a user registration:
User fills out registration form, including the password field.
The web script stores all of the information into a database.
However, the password is run through a hash function, before being stored.
The original version of the password has not been stored anywhere, so it is technically discarded.
And the login process:
User enters username (or e-mail) and password.
The script runs the password through the same hashing function.
The script finds the user record from the database, and reads the stored hashed password.
Both of these values are compared, and the access is granted if they match.
Once we decide on a decent method for hashing the password, we are going to implement this process later in this article.
Note that the original password has never been stored anywhere. If the database is stolen, the user logins can not be compromised, right? Well, the answer is “it depends.” Let’s look at some potential problems.

4. Problem #1: Hash Collision
A hash “collision” occurs when two different data inputs generate the same resulting hash. The likelihood of this happening depends on which function you use.
How can this be exploited?
As an example, I have seen some older scripts which used crc32() to hash passwords. This function generates a 32-bit integer as the result. This means there are only 2^32 (i.e. 4,294,967,296) possible outcomes.

Let’s hash a password:

Now, let’s assume the role of a person who has stolen a database, and has the hash value. We may not be able to convert 323322056 into ‘supersecretpassword’, however, we can figure out another password that will convert to the same hash value, with a simple script:

This may run for a while, though, eventually, it should return a string. We can use this returned string — instead of ‘supersecretpassword’ — and it will allow us to successfully login into that person’s account.
For example, after running this exact script for a few moments on my computer, I was given ‘MTIxMjY5MTAwNg==‘. Let’s test it out:

How can this be prevented?
Nowadays, a powerful home PC can be used to run a hash function almost a billion times per second. So we need a hash function that has a very big range.
For example, md5() might be suitable, as it generates 128-bit hashes. This translates into 340,282,366,920,938,463,463,374,607,431,768,211,45 6 possible outcomes. It is impossible to run through so many iterations to find collisions. However some people have still found ways to do this (see here).

Sha1
Sha1()

is a better alternative, and it generates an even longer 160-bit hash value.

5. Problem #2: Rainbow Tables
Even if we fix the collision issue, we’re still not safe yet.

These tables can have as many as millions or even billions of rows.
For example, you can go through a dictionary, and generate hash values for every word. You can also start combining words together, and generate hashes for those too. That is not all; you can even start adding digits before/after/between words, and store them in the table as well.
Considering how cheap storage is nowadays, gigantic Rainbow Tables can be produced and used.
How can this be exploited?
Let’s imagine that a large database is stolen, along with 10 million password hashes. It is fairly easy to search the rainbow table for each of them. Not all of them will be found, certainly, but, nonetheless…some of them will!
How can this be prevented?
We can try adding a “salt”. Here is an example:

What we basically do is concatenate the “salt” string with the passwords before hashing them. The resulting string obviously will not be on any pre-built rainbow table. But, we’re still not safe just yet!

6. Problem #3: Rainbow Tables (again)
Remember that a Rainbow Table may be created from scratch, after the database has been stolen.
How can this be exploited?
Even if a salt was used, this may have been stolen along with the database. All they have to do is generate a new Rainbow Table from scratch, but this time they concatenate the salt to every word that they are putting in the table.
For example, in a generic Rainbow Table, “easypassword” may exist. But in this new Rainbow Table, they have “f#@V)Hu^%Hgfdseasypassword” as well. When they run all of the 10 million stolen salted hashes against this table, they will again be able to find some matches.

How can this be prevented?
We can use a “unique salt” instead, which changes for each user.
A candidate for this kind of salt is the user’s id value from the database:

This is assuming that a user’s id number never changes, which is typically the case.
We may also generate a random string for each user and use that as the unique salt. But we would need to ensure that we store that in the user record somewhere.

This method protects us against Rainbow Tables, because now every single password has been salted with a different value. The attacker would have to generate 10 million separate Rainbow Tables, which would be completely impractical.

7. Problem #4: Hash Speed

Most hashing functions have been designed with speed in mind, because they are often used to calculate checksum values for large data sets and files, to check for data integrity.
How can this be exploited?
As I mentioned before, a modern PC with powerful GPU’s (yes, video cards) can be programmed to calculate roughly a billion hashes per second. This way, they can use a brute force attack to try every single possible password.
You may think that requiring a minimum 8 character long password might keep it safe from a brute force attack, but let’s determine if that is, indeed, the case:
If the password can contain lowercase, uppercase letters and number, that is 62 (26+26+10) possible characters.
An 8 character long string has 62^8 possible versions. That is a little over 218 trillion.
At a rate of 1 billion hashes per second, that can be solved in about 60 hours.
And for 6 character long passwords, which is also quite common, it would take under 1 minute.
Feel free to require 9 or 10 character long passwords, however you might start annoying some of your users.

How can this be prevented?
Use a slower hash function.

One way to do that would be to implement it yourself:

Or you may use an algorithm that supports a "cost parameter," such as BLOWFISH. In PHP, this can be done using the crypt() function.

The second parameter to the crypt() function contains some values separated by the dollar sign ($).
The first value is '$2a', which indicates that we will be using the BLOWFISH algorithm.
The second value, '$10' in this case, is the "cost parameter". This is the base-2 logarithm of how many iterations it will run (10 => 2^10 = 1024 iterations.) This number can range between 04 and 31.
Let's run an example:

The resulting hash contains the algorithm ($2a), the cost parameter ($10), and the 22 character salt that was used. The rest of it is the calculated hash. Let's run a test:

When we run this, we see "Access Granted!"

8. Putting it Together
With all of the above in mind, let's write a utility class based on what we learned so far:

Here is the usage during user registration:

9. A Note on Blowfish Availability
The Blowfish algorithm may not be implemented in all systems, even though it is quite popular by now. You may check your system with this code:

However, as of PHP 5.3, you do not need to worry; PHP ships with this implementation built in.

Conclusion
This method of hashing passwords should be solid enough for most web applications. That said, don't forget: you can also require that your members use stronger passwords, by enforcing minimum lengths, mixed characters, digits & special characters.
A question to you, reader: how do you hash your passwords? Can you recommend any improvements over this implementation?

 

How about crediting the source?
http://net.tutsplus.com/tutorials/php/understanding-hash-functions-and-keeping-passwords-safe/