Monday, October 31, 2011

"SHA" in hash() is not SHA-1 in CF8/9, it is SHA-0! (according to CFWACK)

UPDATE: I wasn't intend to promote the use of SHA-1 for hashing password, or hashing anything using SHA-1 in general.  This post is here to point out the highly used "SHA" param for hash() is actually SHA-0.  For those who intended to compute a valid SHA-1 hash, please use "SHA-1" as the algorithm param.


Do you know "SHA" algorithm in ColdFusion is actually the broken flawed "SHA-0"?

According to wikipedia
retronym applied to the original version of the 160-bit hash function published in 1993 under the name "SHA". It was withdrawn shortly after publication due to an undisclosed "significant flaw" and replaced by the slightly revised version SHA-1.
And according to owasp.org
SHA-0 has been conclusively broken. It should no longer be used for any sensitive applications.

So please use "SHA-1" instead of the flawed "SHA" if you want a SHA-1 hash.  It is available in ColdFusion Standard Edition.  Somehow it is not in CFBuilder's code assist for hash().

I cannot believe how error-ridden is the CF 9's documentation on hash().  Many errors are carried over from CF 8 documentation and this is unacceptable.  Just read the comments section and you will see that all the returned lengths are stated incorrectly, and many algorithms that are available in Standard Edition are listed under Enterprise Edition only.

Please use Adobe ColdFusion 9 Web Application Construction Kit (block-quoted below).  The list is applicable to CF 8 as well, but I'm not sure about CF7 or earlier.  Also, please read the comments of this post.

.... In ColdFusion 9, the Hash() function also leverages the message digests supplied by the SunJCE provider. 
...
algorithm
Optional. This is the algorithm used to hash the string. ColdFusion includes a backward-compatible algorithm, as well as the default algorithms supported by the SunJCE provider:
  • CFMX_COMPAT (default). Algorithm used in ColdFusion versions prior to MX 7; this is the least-secure option (same as MD5 algorithm)
  • MD2. The MD2 algorithm; generates a 32-byte, hexadecimal string
  • MD5 (default). The MD5 algorithm; generates a 32-byte, hexadecimal string (same as CFMX_COMPAT algorithm)
  • SHA. The original Secure Hash Standard (SHA-0) algorithm specified by NIST FIPS-180; generates a 40-character string
  • SHA-1. The SHA-1 algorithm specified by NIST FIPS-180-2; generates a 40-character string
  • SHA-256. Uses SHA-256 algorithm specified by FIPS-180-2; generates a 64-character string
  • SHA-384. Uses SHA-256 algorithm specified by FIPS-180-2; generates a 96-character string
  • SHA-512. Uses SHA-256 algorithm specified by FIPS-180-2; generates a 128-character string
ColdFusion 9 Enterprise edition includes the following RSA BSafe Crypto-J library algorithms for use with hash():
  • SHA-224. The 224-bit secure hash algorithm defined by FIPS 180-2 and FIPS 198
  • HMAC-MD5. The hash message authentication code calculated using the MD5 hash algorithm
  • HMAC-RIPEMD160. The hash message authentication code calculated using the RACE Integrity Primitives Evaluation Message Digest 160-bit message digest algorithm and cryptographic hash function
  • HMAC-SHA1. The hash message authentication code calculated using the 160-bit secure hash algorithm defined by FIPS 180-2 and FIPS 198
  • HMAC-SHA224. The hash message authentication code calculated using the 224-bit secure hash algorithm defined by FIPS 180-2 and FIPS 198
  • HMAC-SHA256. The hash message authentication code calculated using the 256-bit secure hash algorithm defined by FIPS 180-2 and FIPS 198
  • HMAC-SHA384. The hash message authentication code calculated using the 384-bit secure hash algorithm defined by FIPS 180-2 and FIPS 198
  • HMAC-SHA512. The hash message authentication code calculated using the 512-bit secure hash algorithm defined by FIPS 180-2 and FIPS 198

Tip
If an algorithm is in both the Sun JCE and Crypto-J, ColdFusion will use the one provided by Crypto-J.

3 comments:

  1. Yeah, don't use SHA-1 either. It's been broken for 6+ years. Encouraging its use is bad advice.

    http://www.schneier.com/blog/archives/2005/02/sha1_broken.html

    Use at least SHA-256. Or SHA-512 is even better. Or if you are doing this to hash passwords, which I assume you are, look at BCrypt.

    ReplyDelete
  2. Thanks for digging this up Henry. The Adobe docs for hash always looked wrong to me but I didn't realise how wrong it was until now.

    Jason: I think you're missing the point here. The issue is that developers who have a reason to use SHA-1 will look at Adobe's docs and think that Hash(value,"SHA") will give it to them.

    It's true that SHA-1 is "cryptographically broken". This means that there is a known attack that can find a collision more efficiently than a brute force search. In the case of SHA-1, the known attack is at least 2,000 times more efficient. SHA-1 is only 160 bits to begin with, so it's poor choice nowadays for applications such as trusted authentication.

    However there are plenty of other ways to use a hash algorithm. One popular application is to "key" large content objects such as files, BLOBs or CLOBs. For example, the distributed source control systems Git and Mercurial both use SHA-1 checksums to uniquely identify commits. However there are no known security weaknesses in either system for their use of SHA-1, and there is no serious proposal I know of for upgrading either system to stronger hashes.

    Even if you are using a hash algorithm for hashing passwords, the speed (or should I say slowness) of the algorithm is more important then the cryptographic strength. BCrypt actually uses a variant of 64-bit Blowfish which is weaker than broken SHA-1 (68-bit strength) but really slow to set up. Bcrypt then runs the input through thousands of rounds of this agorithm to create a very secure password hash.

    P.S. I would *love* it if SHA-1 really were completely useless, as it would mean all the Git fanbois would have to either go back to Subversion or switch to Bazaar! MUAHAHAHAHAHAHA

    ReplyDelete
  3. Thanks Jason and boomfish. I have updated the post to hopefully clear up the true intent of this post.

    ReplyDelete