Welcome!

ColdFusion Authors: John Ryan, Fuat Kircaali, Yeshim Deniz, Anatole Tartakovsky, Steve Lesem

Related Topics: ColdFusion

ColdFusion: Article

Data Encryption in ColdFusion: An Overview of the Built-in Features

CF didn't used to offer much in the way of built-in data encryption; that all changed in CFMX 7

It is likely that at some point in your development career you had to deal with sensitive data. It might have been credit card numbers in an e-commerce site, or an employee identification number on an intranet. Perhaps you were setting up a security scheme and wanted to protect the passwords of the user.

Maybe you wanted to encrypt some user data before sending it off to a business partner via a Web service, or setting a cookie on the user's machine? For whatever the reason you probably took a look at ColdFusion's built-in functions for encrypting data.

Unfortunately, in versions of ColdFusion prior to the seventh release, ColdFusion didn't offer much in the way of built-in data encryption. You had to go looking outside of the built-in functionality, and often purchase a custom tag to do anything advanced with encryption. Thankfully, ColdFusion MX7 expanded the built-in encryption set and gives us a much broader range of features without going outside the language. This article will tell you about those features and offer some suggestions on where to go when you need more.

Password Encryption
Have you ever come across a Website that forces you to register to see their content? If so, have you ever tried to register only to be told that you already have an account? In the dark reaches of your mind, you have a vague memory of trying to access some content on their site many years ago. They won't let you re-register because you already have an account, so you click that "I forgot my password" box. Many sites will not reveal your password to you. A common approach is for you to provide an e-mail address, and then the site will reset your e-mail address and e-mail you the new one. Another approach might be for you to answer a series of password questions, after which you will be able to reset your password.

Why do you have to reset the password, instead of the site revealing the previous password to you? It's because they don't know the password. As part of the security process, they encrypt all passwords in their database, using a one-way algorithm. A one-way algorithm is a method of encryption where the encrypted string cannot be decrypted. There is no way to get the original data from the decrypted string. In ColdFusion you can set up this type of encryption using the hash function.

The hash function has three arguments:

  • String: The string argument specifies the data you want to encrypt.
  • Algorithm: The algorithm argument specifies the algorithm you want to use to generate your encrypted string. The algorithm selected will affect the length of the encrypted string. CFMX_COMPAT or MD5 will generate a 32-character string, compatible with previous version of CFMX. SHA will generate a 28-character string, SHA-256 a 44-character string, SHA-384 a 64-character string, and SHA-512 a 88 character string.
  • Encoding: Encoding is an option attribute that is used to specify the encoding to use when converting the string to byte data. If you leave out this attribute, the defaultCharset value, set in neo-runtime.xml, is used.
So, how can you apply this to your own development? Suppose you had a registration form on your Website. The users fill out a bunch of information, including username and password. The form probably looks something this:

<form action="save.cfm" method="post">
   username: <input type="text" name="username">
   password: <input type="password" name=" password">
   .. other user stuff here
</form>

The user steps through the registration process and at some point they submit the form. Your verification code decides that there is no problem with the user's submission, and you'll run an insert query like this:

<cfquery name="savestring" datasource="Mydb">
   insert into Users(username, password, otheruserstuff)
   values ('#form.username#', '#hash(form.password)#', 'otheruserstuff')
</cfquery>

Although you collected a plain text password, you don't actually store it in that format. The information is hashed when it goes into the database. How do you actually compare that information when the user tries to log back in? Easy, you hash the password they entered and compare the hashed results with the hashed value in the database.

Suppose this is your login form:

<form action="login.cfm" method="post">
   username: <input type="text" name="username">
   password: <input type="password" name=" password">
</form>

(Hey, that code snippet looks familiar.) The user clicks submit and, on the login page, you can verify the login like this:

<cfquery name="Login" datasource="Mydb">
   select * Users
   where username = '#form.username#' and password = '#hash(form.password)#'
</cfquery>

There you have it. More information about the hash function can be found in the livedocs http://livedocs.macromedia.com/coldfusion/7/htmldocs/00000503.htm#1105551.

Data Decryption
One drawback of the hash function is that you are never able to take the encrypted value and get the original string. Sometimes, you'll need to see the data behind your encrypted strings. ColdFusion has two functions to help us with this, aptly named encrypt and decrypt. Both functions have a similar set of arguments:

  • String: The string argument is required. It is either the string that you want to encrypt (for the encrypt function) or the encrypted string you want to decrypt (for the decrypt function)
  • Key: The key argument is used to specify the key for encryption and decryption. You use this value to go from the original value to an encrypted string, and to go from the encrypted string back to the original value. If you are using CFMX_COMPAT (which is included for backward compatibility), any string can be used in the encrypt function. Otherwise, you should use the GenerateSecretKey function to create a key for the particular algorithm. For decryption, you should use the same key value that you used to encrypt the value in the first place. GenerateSecretKey accepts one argument, which is the name of the algorithm.
  • Algorithm: The algorithm argument accepts the name of the encryption library that you want to use. CFMX_COMPAT is the default value, making this argument optional. Other values are AES, Blowfish, DES, or DESEDE.
  • Encoding: The encoding argument is used to specify the binary encoding that is used to represent the data as a string. UU is the default value, with the alternate's being Base64 or Hex.
  • IVorSalt: If you are using a block encryption algorithm, you need to specify the initialization vector (IV) for compatibility with other systems. You put that value here. For password-based encryption, specify the salt value here. A salt value is random data that is part of the session key and helps deter brute force decryption attempts.
  • Iterations: The iterations argument specifies the number of iterations that are taken to transform the password into a binary key. This argument is not used for block encryption algorithms.
For this example, I'll assume you need to integrate two systems and must send data from one to the other, via an HTTP post. (Believe it or not, my experience is that this method is still in wider use than SOAP Web services.) First, you need to create the page to send the data:

<cfset data = encrypt('Jeff','12345')>
<cfhttp url="http://localhost//recieve.cfm" method="post" result="MyResults" >
<cfhttpparam name="data" value="#data#" type="formfield">
</cfhttp>
<cfdump var="#variables#">

About Jeffry Houser

Jeffry is a technical entrepreneur with over 10 years of making the web work for you. Lately Jeffry has been cooped up in his cave building the first in a line of easy to use interface components for Flex Developers at www.flextras.com . He has a Computer Science degree from the days before business met the Internet and owns DotComIt, an Adobe Solutions Partner specializing in Rich Internet Applications. Jeffry is an Adobe Community Expert and produces The Flex Show, a podcast that includes expert interviews and screencast tutorials. Jeffry is also co-manager of the Hartford CT Adobe User Group, author of three ColdFusion books and over 30 articles, and has spoken at various events all over the US. In his spare time he is a musician, old school adventure game aficionado, and recording engineer. He also owns a Wii. You can read his blog at www.jeffryhouser.com, check out his podcast at www.theflexshow.com or check out his company at www.dot-com-it.com.

Comments (5) View Comments

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.


Most Recent Comments
Jeff Houser 11/08/07 06:18:11 PM EST

Joshua,

A lot of things have changed thanks to PCI Compliance. I am not up on them, but here is a place to start:

https://www.pcisecuritystandards.org/

I strongly recommend anything you do comply with such guidelines.

Joshua Rountree 11/08/07 11:22:32 AM EST

Hey, if you had to store credit card data in a database would you also store the key that was generated in a separate field?
How would you handle this for decrption purposes?

Please advise, thanks!

Jeff Houser 02/13/06 12:44:21 PM EST

Based on recent tests, It appears that the latest version of PGP (9.05) will not break the CF WSConfig tool. When I wrote this article I was using 9.02, which caused a lot of problems.

Jeff Houser 02/13/06 12:42:32 PM EST

Hi queZZtion,

Who knows what the next version will contain. Yes, I hope that CF adds native support for public / private key encryption. I don't know if it is being considered (or not).

news desk 01/25/06 09:54:35 PM EST

It is likely that at some point in your development career you had to deal with sensitive data. It might have been credit card numbers in an e-commerce site, or an employee identification number on an intranet. Perhaps you were setting up a security scheme and wanted to protect the passwords of the user.