What is salting?So statisticians will sometimes ask you silly questions about Monty Hall and about Birthdays. The Birthday problem is the one that we are most concerned with as security professionals. The Birthday Problem states that if you compare the birthdays of 23 random people, there is more than a 50% chance that two of those people will have the same birthday. The reason this concerns us is because many knuckleheads use their Birthday as their password, or their PIN number. Other dates they may use are kids' birthdays, anniversaries, date they lost their... er uh.. wallet. Well, you get the idea.
So it occurs to password crackers that if people are using these dates for password, and if there are only 366 different dates then they could very easily make a hash look up table of all the possible date hashes. Additionally, if they did compromise a database and get a list of hashed passwords, they could look for duplicates and make a close to accurate assumption that they are likely dates. Even with all of the variations of date formats that people could enter, there are really less than 10,000 possible date passwords.
So what can we do about it? We can't stop the knuckleheads from using dates for passwords, can we? Well, actually, you could. I forgot to add a check to my post the other day to use the IsDate() function to give an error on a password if it returned true. But regardless, dates are not the only issue here, they are just a good example. There are other common passwords that could be placed into a hash table, like "123456" and "letmein" or any of the words in the dictionary. We can't check our users' input for every possible stoopid password they could enter. So what do we do when are users enter passwords that are likely to be found in rainbow tables? The answer to this issue is to salt the passwords.
Salting is the process of adding a random string of characters to the end of a user's password (or other sensitive data) before hashing it. Each password would get its own salt hence eliminating the problem of two like passwords having the same hash value.
Yay! More code!
<cfset val1 = "Password1" />
<cfset val2 = "Password1" />
<cfset hash1 = Hash(val1, "MD5") />
<cfset hash2 = Hash(val2, "MD5") />
<cfset hash1Salted = Hash(val1 & CreateUUID(), "MD5") />
<cfset hash2Salted = Hash(val2 & CreateUUID(), "MD5") />
Value 1 Hashed:#hash1#<br />
Value 2 Hashed:#hash2#<br /><br />
Value 1 Salted and Hashed:#hash1Salted#<br />
Value 2 Salted and Hashed:#hash2Salted#<br />
Will give us this output:
Value 1 Hashed:2AC9CB7DC02B3C0083EB70898E549B63
Value 2 Hashed:2AC9CB7DC02B3C0083EB70898E549B63
Value 1 Salted and hashed:2DEB5ADAF0854BBBC24DC4797BA73027
Value 2 Salted and Hashed:3498DD83CA3F1945D0EE7BE16984999E
Notice that when only hashed, the two identical values yield the same result, but when hashed and salted the two values yield very different results. This will help combat Birthday attacks, dictionary attacks, and other types of brute-force password attacks against your application.
Great question. Huh, I hadn't considered that.
I'm kidding, I actually did consider that. The answer is that we store the salt. We put it in the database, probably in another table, and join it to the user. Then when the user send the password via the authentication form we append the salt to the user input and hash the value, then compare that to the hashed password value in the database. If the values match, the correct password was sent. We will cover how we actually do that in my next post, sometime next week.
Another great question. Geez, you are on top of this. The answer to that question, however, is no. In fact, the salt itself is really only being used to obfuscate the real password in its hashed form to prevent common passwords, like dates, "password", "123456", and the administrator classic "IamGod" from being found in a rainbow table attack. Gaining access to the salt list would get the hacker nothing more than he/she would get from performing a brute-force attack against your application via the login form. Heck, you could probably even put your salt list on your "About" page. Since a hash cannot be "reversed", having the salt will not give a hacker what they need to reverse engineer the hash into a real password with the salt appended to the end of it. Maybe somebody knows something about this that I missing, if so, please let me know, cause I want to be accurate. But based on what I know, the salt value is close to useless to a hacker.