|
The Coldfusion Hash() function decoded - kind of |
I've always believed that using the hash() function in ColdFusion is a one way process. If I wanted to reverse a string I had to use encode() and decode(). The Adobe documentation states that "It is not possible to convert the hash result back to the source string" - Adobe Docs for Hash().
Strictly speaking this is still true, but some bright spark has decided to host an MD5 string database and provide a lookup service.
The Hash() function has been around for a long time, in pre ColdFusion 7 versions of it you could not specify an algorithm, so you could only encode to MD5 standards.
In most cases the algorithm did not really matter too much. Most developers would have used hash() to store a password and perform real time character checks against the database values when a user submits a password string.
2
3<cfset variables.encodedValue = hash('myPassword')>
4
5<cfoutput>#variables.encodedValue#</cfoutput>
6
7Results in:
8DEB1536F480475F7D593219AA1AFD74C
You could 'in-effect' never actually get a password back again, only perform a check against it using other hash()-ed strings.
The site http://www.md5decrypter.com/ appears to be hosting a database containing '8,076,999 unique MD5 hashes'. I've tested over a dozen random strings and they have all been successfully returned from their search.
It is probably more of a legacy application issue, but it is definitely worth noting that you really should specify an algorithm type when using the hash() function now.
This really makes a good case for revisiting those 'old' applications that never get a budget for bringing up-to-date.
Looking at the statistics though the more complex algorithms would need exponentially more records as they are many times more complex. This is even more evident if you compare the length of the same string encoded with MD5 and any one of the SHA algorithms.
Joking aside, I wanted to thank you for the thought provoking tweet. It gave me incentive to do more writing than I have in a while.
Glad I've re-ignited an interest :-)
@Ron, good point, any custom manipulation will greatly have an impact on the security of the data. Unless your manipulation device is unsecure, then you've just given the key to the vault away.
Every user has a random salt calculated which is mixed with their password before hashing, ensuring that someone who gains access to the database cannot simply do a hash lookup to obtain a password.
Here's an article that starts with over-simple plain text passwords, then takes steps to explain why salt makes sense, and how to be most secure:
http://www.developerfusion.com/article/4679/you-wa...
@Dominic, interesting idea. I wouldn't be surprised if it was possible to do that, or perhaps they even have an API they just haven't exposed.
Good to see there is an official GVMT standard.