How do I use encryption in ColdFusion?
ColdFusion makes it simply to use encryption to protect sensitive data. The basic process to encrypt data requires you to select a key. This key is used to both encrypt and decrypt the data. The same key must be used for both operations. Once you have selected a key, the code is simple:
<cfset string = "my credit card number">
<cfset encrypted_string = encrypt(string,key)>
To decrypt the string, just reverse the process:
ColdFusion supports multiple types of encryption. These include AES, DES, DES-EDE, DESX, RC2, RC4, RC5, SHA1, SHA-256, HMAC-MD5, and others as well. The level of encryption supported depends on the edition of ColdFusion being run. ColdFusion also supports an encryptBinary and decryptBinary to support encryption of binary data.
This question was written by Raymond Camden.
It was last updated on August 6, 2007 at 9:34:24 AM EDT.
Categories
Comments
Comment made by Brian Kotek on August 6, 2007 at 11:37 AM
Actually it turns out that in CF8, many of the encryption algorithms won't work. The CF team is working on an enhancement request to add these in, but as it stands, the following alogrithms cannot be used in any version of CF8:
DES-EDE, PGE, HMAC-MD5, HMAC-RIPEMD160, HMAC-SHA1, HMAC-SHA224, HMAC-256, HMAC-384, HMAC-512, DSA, Diffie-Hellman
Comment made by Raymond Camden on August 6, 2007 at 12:23 PM
Yeah, I normally write these entries with the idea of 'it should work as documented'. ;) So you heard back from Adobe? They admit it is broken?
Comment made by Brian Kotek on August 6, 2007 at 3:28 PM
Technically they don't think it is broken (though they did say the docs need to be changed to reflect what actually will work). Personally it seems like it should work the same way Encrypt() works with the other algorithms. It's the same arguments as any other Encrypt() call (value, key, algorithm). So they don't admit it is broken (even though I would say it is), but they do admit those algorithms won't work, and they have submitted an enhancement request to get them to work.
Comment made by Raymond Camden on August 6, 2007 at 4:10 PM
I'm confused. Are they saying it is a doc issue? What doc issue then?
Comment made by Adam Tuttle on August 9, 2007 at 3:00 PM
Sounds like instead of admitting that the code is broken, they are saying that the spec is wrong (same thing...) and that they have submitted an ER to have the newly non-working algorithms added back in.
Comment made by Adam Tuttle on August 9, 2007 at 3:01 PM
Erm - I meant doc, not spec.
Comment made by Tom on November 20, 2007 at 4:26 PM
So is this method suggested to store encrypted credit card numbers in a database? Your thoughts?
Comment made by Raymond Camden on November 20, 2007 at 4:29 PM
I think most folks would recommend against storing the CC # at all.
Comment made by Tom on November 20, 2007 at 10:58 PM
Ray I agree, but my customer insists on storing this info.
Comment made by JC on May 29, 2008 at 10:42 AM
AES, BLOWFISH, DES, DESEDE, DESX, RC2, RC4, RC5 -- these work for encrypt()/decrypt()/GenerateSecretKey()
MD2, MD5, RIPEMD160, SHA-1, SHA-224, SHA-256, SHA-384, SHA-512 -- these work for hash()
DH ,Diffie-Hellman, DSA, RSA -- these are public/private key methods and while they may work somehow, no one seems to know and adobe hasn't provided any sample code. (DH = diffie-hellman)
PBE doesn't do anything, it's referring to the *unlisted* PBEWithMD5AndDES and PBEWithMD5AndTripleDES, both of which work for encr/decr but you must provide your own secret key. The same applies to CFMX_COMPAT.
HMAC-MD5, HMAC-RIPEMD160, HMAC-SHA1, HMAC-SHA224, HMAC-SHA256, HMAC-SHA384, HMAC-SHA512 are almost certainly just documentation mistakes, as they replicate the above, working algorithms.
Some of the algorithms require you to go to Sun's website and download some stronger encryption files - CF ships with the international version, strong encryption requires the US version that cannot be downloaded from cuba/north korea/etc (there's a note in the Encrypt() function livedocs vaguely mentioning this now... I've been emailing with the Adobe guy to try and make some sense of the stuff but he's a documentation person, not a programmer, I think.
And storing CC numbers in the database is bad news, but if you have to do it, it would be really nice if Adobe would get that public/private encryption thing working.
Barring that, encrypt the first 8 characters with DESX and the remaining characters with MD5 (or whatever, pick two of the stronger reversible ones), check the length of each, convert the lengths some uncommon numeric base, concatenate them with some kind of delimiter, pad it to 20 with a static string, encrypt that and store it in a different field, then hash the current timestamp + some random song lyric or horrible one-line joke using SHA-512, plop that between the two halves of the cc number, and if you really want to have fun, then stick 1 or 2 random nonsense characters between every second or third character based on whether the first character in the horrific mess has an even or odd ASCII value. And then encrypt the whole mess of it with something lightweight so it all looks the same.
Reasonably easy for you to decode... decrypt the giant ugly thing, strip out the nonsense characters, grab the lengths, right()/left() the meaningful info and decrypt it, combine them to get the credit card number. Performance may not be great, but if someone gets into your database and can figure that mess out, they've earned it.
Of course, if they can get at your CF source code, that renders it all pretty much moot. Of course, you can encrypt the CF code (cfencode, was it? does that even still exist?) and hope the evil cracker doesn't know enough about CF to decrypt it.