Hashing iterations and how it is used to re-enforce hashing procedures for protecting user passwords.
Episode #4-02 released on September 22, 2013
Hash iterations are an exceptional way at dealing with some of the many advantages of hashing algorithms. Hashing algorithms are designed to be fast, and reproducible. They are strictly one directional, and provide very little security, as a result. Production machines can produce thousands, millions, even billions of computational hashes per second, so a single hash iteration will not suffice.
Another issue that plagues hashing, is hash collisions. It is possible for two different sets of data to produce the very same hash result. This means that the password of a user account is no longer important, only the resulting hash. In this way, knowing the resulting hash can lead to someone being able to reverse engineer passwords using a rainbow table, which doesn't even need to be as accurate as some would lead you to believe. In this episode, I talk about each of the issues I just referenced, and how it may be solved by using numerous computational hashing iterations.
First, hash collisions. Especially with lower bit length hashing algorithms, it is possible to get the same result for numerous different sets of data when hashing, because of the fixed length and character possibilities available for the hashing result. If we understand that a standard hash result contains all 26 upper and lower case characters and all integers from 0 to 9, and we understand that MD5 which has a character length of 32 when hex coded, thus there is 32 to the power of 62 possible hash results, or 2 trigintillion possibilities of results. For password purposes, we don't need to reproduce anywhere near that many possibilities. It is however, still possible, if not exceptionally rare that two identical responses will occur. It should be noted that using longer bit length hashing algorithms like SHA-256, 512, or better than using the broken MD5.
Reproducibility is one of the many strengths of hashing, irregardless of how the sequence is achieved, if it uses single or multiple iterations, the resulting answer is the same. This being fact, this means we can use iterations reliably. This, also, makes hashing weaker, because the result is always the same.
Rainbow tables, are a collection of targeted results that are designed to allow various malicious users the ability to steal others accounts and allow for better targeting of victims. Due to the fact that many users may repeat password rules, or passwords on many web-sites, and usernames rarely different, it can be determined that a user may lose their account to another malicious user if they account was ever compromised during a hack, through the use of a rainbow table for a targeted length of passwords.
Knowing that hashing is reliably constant, and fast, means we can use iterations to generate more secure hash results that reduce the chance for hash collisions, and if we use random and unique salts for each of the users, while iterating our hash engines, we can, also, significantly slow down attackers by forcing them to need more processing power to produce a rainbow table for each user.
The only draw back is that if we use an iteration count that is too high, with too many users logging in, we run into the risk of DDOSing our own servers. Therefore, we must determine how many iterations our servers can safely handle, while making the resulting hash as safe as we possibly can. For convenience, we should note that many companies resort to time requirements for determining how many hash iterations they should use. Speaking in server time, a single second of server time can be equal to hundreds of thousands, even millions of iterations depending on the processing power of the server.
A simple way to create an iteration counter script is to use a loop with a counter that adds one for each loop, and hashing the given result from the previous loop at the same time. If your counter starts at 0 and you add 1 for each loop, and you have the loop go for 2048000 times, it should look like this if using the while function within PHP.
$x=1;
while($x<=2048000)
{
$int_enc_pswd = HASH('SHA512', $int_enc_pswd, $raw);
$x++;
}
$enc_pswd = $int_encrypted_password;
You would then use the $enc_pswd in this example as the result to compare with the database. You may copy, and use the above script for your own projects. If you know any other languages and wish to have them added to the show notes, please email ask@tqaweekly.com and share with the world. Note: You must also produce the original password through the same means. And, make sure you add a unique and random salt for each user.
Next week, I will be talking about iOS7, my top 5 favorite features, and 5 most hated features as well.
Remember to like this episode if you were interested in today's topic, share if you think someone else could benefit from the topic, and subscribe if you want to learn more. For the show notes of this episode and others, for more information on other ways to subscribe to our show, to subscribe to our weekly newsletter, and how to participate by submitting your questions, comments, suggestions, and stories, head over to TQAWeekly.com.
Host : Steve Smith | Music : Jonny Lee Hart | Editor : Steve Smith | Producer : Zed Axis Productions