After a long break in my series of the little enhancements in ColdFusion MX 7 (CFMX 7 Little Things), I am back today with another article, this time with the Hash function.
In versions of ColdFusion prior to 7, the Hash function used the MD5 algorithm to generate hash values. In version 7 you can specify which algorithm to use, and the new choices are:
- SHA - Generates a 40 character hash string using the Secure Hash Standard SHA-1 algorithm
- SHA-256 - Generates a 64 character hash string using the SHA-256 algorithm
- SHA-384 - Generates a 96 character hash string using the SHA-384 algorithm
- SHA-512 - Generates a 128 character hash string using the SHA-512 algorithm
Here's a code example that generates an 128 character hash, which is pretty large:
<cfoutput>#Hash("myPassword", "SHA-512")#</cfoutput>
CF 7 Also adds an encoding argument, which according to the docs:
Must be a character encoding name recognized by the Java runtime. The default value is the value specified by the defaultCharset entry in the neo-runtime.xml file, which is normally UTF-8
The Hash function is most commonly used as a one way encoding for passwords. If you don't want to store a users password in your database in plain text, you can store the Hash of the password. Then when the user logs in instead of comparing the password with a value from your database, you compare a Hash of the input password, with the Hash of the users password in the database.
There is no known way to reverse a hash (except through brute force or pre-computing values - known as a rainbow table), so if your user forgets their password, you cannot email it to them, you have to come up with another way to authenticate the user, in order to reset the password.
Update 2024: These days there are much better algorithms to use for password storage such as PBKDF2, bcrypt, scrypt, Argon2, etc. If you do use a SHA2 hash algorithm be sure to use a salt, and hash iterations.
Comments
Note that in addition to the new hashes listed, you can still specify MD5 (which is the default) to use the same algorithm as prior versions of CF. It's helpful to be able to specify the default, because it will allow you to store the hash algorithm in the database for a given password, and then migrate passwords to a different hash algorithm as they are updated, for example.
Pete, One other thing to have developers consider is using a salt (a random string stored in an additional db column, and prepended to the password before hashing) along with the Hash. Salting the password before hashing it makes it virtually impossible to launch a successful dictionary style attack against the hashed password values stored in the database because an attacker would have to try all of the possible salt values for each hash value in their dictionary. For example, if you use a 12-character string consisting of upper case letters from A to Z, there are 26^12 possible salt combinations for each password.
Rob that is a great idea, i've never heard of that. The attacker would not necessarily even know if the hash had been salted. Thanks for the tip.
Ryan, an attacker will know salt is being used, because they'll see the 'salt' column in the table. But that's fairly irrelevant, and may actually deter the attacker from continuing, because the chance of success is so greatly reduced.