Hashing passwords differs to encrypting passwords in that they contain irretrievable information. If you encrypt a block of data, there would exist a way to decrypt it back to its original form. Hashes create a 128 bit hash value (this typically consisting of a 32 digit hexadecimal number).
The use of hashing passwords (in particular MD5) can be used to confirm receipt of files in their original form. If a user was to run the MD5 algorithm on an exe file, it should be identical the other end. The recipient can then run the same MD5 algorithm on the file and if they finds the MD5 hash value to be different, it’s a significant indicator that the file has been tampered with en-route.
MD5 also finds itself used quite heavily to store passwords, particularly in online applications. There are some security issues with how people implement this. If one simply hashes the value of a password, for example “Password” we get the value dc647eb65e6711e155375218212b3964. If this is run on any computer in the world the result would be the exact same hash value.
Many users have set up databases with the sole purpose of hashing every possible alphanumeric password combination (some still growing) called Rainbow Tables. Within this, an unknown user could potentially look up the hash value and in return, the Rainbow Table could provide the original value as it has it stored. This applies to SHA128 256 and all other hashing passwords procedures.
Unfortunately in many instances, users can’t prevent their hashes being looked up online, nor can they enforce a 14 character alphanumeric password policy on every end user of your applications, however there is one known method called Salting.
Salting has been around for some time and isn’t a hidden IT security method, it’s simply not as publicly known. It’s a way of adding additional data to a string before the hash calculations are performed and in turn, making the string too long to be stored within a Rainbow Table.
- Your password = “Password”
- Your ‘salt’ = “H!##02byPa++sfe”
When you then add the hashing password and salting password together, the 2 values as one string “PasswordH!##02byPa++sfe” is now b7d81ec99d5056c3058d7ea0aef02dfe. This is different to the original hash but to the end user, they still have an 8 character password. Should the event occur where your salt value is exposed to the public, one can then compile their own Rainbow Table taking their salt value into account. To counter balance this and make it even more difficult, we can add another value specific to the users account. As additional protection, the user could also use their ID in the SQL database.
This option is better as user 2 and user 7 can both have the password of “Password” but consequently have different values. You could even add an additional salt value per user to add more characters to the hashing password.
This method should prevent a vast majority of blind brute force attacks on your web applications.