Encrypting Cookie Data with ASP.NET

WEBINAR:On-Demand

My last article, Tracking Visitors with ASP.NET, showed how to use cookies to keep track of site visitors across sessions. I also discussed privacy issues concerning the use of cookie data, particularly if you are storing sensitive information about your visitors/users. It is always a good idea to publish privacy statements to inform your users about how their data is being used and stored on your Web site.

Cookies can provide a real convenience to both visitors and programmers of a Web-based application. However, cookies are problematic from a security point of view for two reasons. First, unless your site uses SSL, cookie data is passed in the clear in the header of both the HTTP request and response. That means anyone who is clever enough to sniff packets on a particular port of a particular IP address can read cookie data as plain as day. The second problem is that cookie data is stored in nice little unrestricted cookie files in a browser's cache directory. This means that anyone that has access to your hard drive can see and open your cookies. Figure #1 shows an example of the contents of a cookie file.

So when your 16 year old finds this "convenient" data and forges off to rack up thousands of dollars in charges on www.HottiesBareAll.com, it will suddenly become clear why cookie security is important.

If you have never seen the voluminous quantity of cookie data on your machine, try the following. Open Internet Explorer, select Tools and then Internet Options from the menu. From the Internet Options dialog click the Settings button. Then on the Settings dialog click View Files. An Explorer window will display all the cached data your browser has kindly filled your hard drive with. Sort the list alphabetically, then scroll down to the Cs. (C is for "Cookie" :)) On my machine, there are currently 1,850 cookie files.

So, here is some advice - don't store sensitive data about users in cookies. If you must, then you have a responsibility to protect that data through encryption.

In previous versions of ASP, you would have been forced to purchase third party components to handle this encryption, or, if you are a genius, you could have ventured off and created your own components. However, most of us resorted to simple techniques that shift the ASCII values of each character in a string, like Rot13. Unfortunately, these techniques are more than obvious to people that are clever enough to sniff packets in the first place. Nevertheless, here is an example of a Rot13 algorithm implemented in ASP:

Fortunately, we no longer have to implement our own feeble security algorithms since the .NET Framework provides us with a slew of encryption classes in the System.Security.Cryptography namespace. Take a look for yourself.

First, let's just acknowledge that encryption is really complicated. Frankly, it's supposed to be complicated because that is what makes it secure. And, by the way, I want to state here that I am in no way an encryption expert. There are probably only a handful of people that fully understand the intricacies of the math involved, and half of them probably wrote the cryptography classes for the .NET Framework.

Fortunately, we don't have to understand the intricacies to take advantage of encryption because the .NET Framework gives us a simple way to access the power of the best and most secure algorithms.
Before we begin encrypting our cookie data, we should have a little discussion about the cryptography classes and which ones are appropriate for securing our cookies.

What Is Encryption Exactly?

In the simplest terms, encryption is the process of taking a target string of characters (bytes, more specifically) and converting it into another string of characters so that by examination, the original characters cannot be deciphered. This process is performed with a second string of characters known as a "key". In technical terms, this key is mathematically "mashed" into the original string over many complex and compounded iterations. In addition, sometimes another string of characters, known as an "initialization vector", is "mangled" into the target string before the key is mashed. This helps to prevent obvious patterns in the target string from being revealed by mashing alone. Of course, the mashing and mangling is not permanent. If the key and the initialization vector remain intact, then the algorithms can use them in reverse to unmangle and unmash the original data.

The effectiveness or "strength" of the encryption is determined by the size of the key used. The larger the key, the stronger the encryption. Typical key sizes are 64 bit (8 bytes), 128 bit (16 bytes), 192 bit (24 bytes), 256 bit (32 bytes) and 512 bit (64 bytes). The only way to crack most of these algorithms is by sheer brute force, where an attacker creates a program to test every single possible key combination. For even the 64-bit option, there are 72,057,594,037,927,936 possible combinations (2^56 - 8 bits are held for parity). So basically, unless you have a very powerful computer, you are going to be waiting awhile to crack even the weakest key.

Cryptography Patterns

There are two basic approaches for handling data encryption: symmetric (or private key) and asymmetric (or public key). In symmetric cryptography techniques, both sides of the data exchange (the encryptor and decryptor) must have access to a single secret private key.

In asymmetric encryption, one side (the decryptor) requests a public key from the encryptor. The encryptor creates a public key and sends it to the requestor. Then the encryptor uses the public key to create a second unique private key that it holds on to. This new private key is used to encrypt the message sent to the decryptor, who then uses the public key to decrypt the message. If encrypted data must be sent in the other direction then the other side will create a new public key and sends it along in a reciprocal fashion. This asymmetric technique is used by SSL to secure HTTP transmissions.

For our cookie encryption purposes, we will use the symmetric approach since both the encryption and decryption will take place in the same application on the server; therefore, we only need one private key that we will keep secure in the compiled code of our cryptographic utility class.

In our example project, we will demonstrate both the DES and TripleDES algorithms. Each of these algorithms is accessed through wrapper classes categorized as Cryptographic Service Providers (CSP).
All CSP objects have two important methods: CreateEncryptor & CreateDecryptor. Each method has two parameters for our private key and initialization vector. Each method returns an algorithm object with the ICryptoTransform interface. This object will be used by the CryptoStream object(which we will discuss in a minute.)

For more a in-depth discussion of Cryptography in .NET, visit the following link in the MSDN Library:

DES is one of the weaker encryption methods because its key size is limited to 64 bits. However, for our cookie purposes, this level of encryption is probably sufficient. TripleDES, which, believe it or not, performs the encryption three times, also has a larger key size. The length of the key must be either 128 or 192 bits - two to three times larger. TripleDES is significantly more secure.
Deciding which algorithm to use should not only be based on your desire for stronger encryption but also by the size of the cookies you require. You will notice in our example application that encrypted data will grow in size. And of course, the larger the key, the larger the resulting data. This is an important consideration since cookie data is restricted to 4kb.

An alternative is to store data that you only need to persist temporarily in hidden input tags. Of course, this is exactly what ViewState does in ASP.NET. In addition, ViewState offers some built-in encryption. The ViewState of a Web form, by default, uses hash functions from some of the asymmetric algorithms to garble the content. This is not fully secure. However, you can configure your ASP.NET application or individual pages to use more secure encryption on the ViewState - specifying the same TripleDES algorithm we discussed earlier.

Of course, if you are carrying that much data around in cookies, you really should reconsider you Web-application design. Remember, each request made of the server will need to pass this cookie blob back, unnecessarily chewing up bandwidth.

Finally, encryption is a processor intensive activity. The more data you are encrypting/decrypting or the stronger your algorithm, the more server resources you will require, potentially slowing down the entire site.

The CryptoStream Object

One of the things you may find hard to understand at first is that all encryption and decryption in .NET is handled through the CryptoStream object. I know you are thinking that all we need to do is convert a few strings. Why do we need to mess with complicated streams. Well, from the broader scope of cryptographic issues and from the design emphasis of the .NET Framework, using streams really makes sense. Nearly all access (IO) to external resources handled by the .NET Framework is done through the use of streams. While it is not in the System.IO namespace, the CryptoStream object inherits from the System.IO.Stream object.

The major advantage of using streams is that they can be chained together. This is particularly useful when performing file operations or accessing other network services. For instance, you can open a socket to a network service and stream data that is simultaneously being encrypted. The following link provides an example of DES provider encrypting a file through streams.

So, in order to work with strings as a stream, we need to utilize a special class called a MemoryStream. This will allow us to handle strings as streams and flow them through the CryptoStream for processing.

Creating a Simple Cryptography Utility Class

Well, you have all been waiting patiently, so here is the code for our CryptoUtil class. As with many utility functions, these don't require state so all our methods are shared (static).

Note that our keys are initialized at the top as an array of bytes. Also, note that I am using numeric constants in these arrays. If you choose to do the same, be sure to keep the values greater than or equal to zero and less than or equal to 255. This is the allowable range for a byte value.

In the class, we have 2 pairs of functions for encrypting and decrypting under both the DES and TripleDES providers. On the encrypt functions, the final byte array in the Memory Stream buffer is converted back to a string using the ToBase64String function. The reverse is done on the decrypt functions with the FromBase64String function.

Creating a Cookie Utility Class

Our next step is to create a simple class for setting and retrieving either plain cookies or those with encryption on top. Again we use series of shared methods to simplify the setting and getting of cookie data, allowing you to handle cookie data with one line of code.
Imports System.Web

You'll notice most of the set functions are overloaded to provide an addition parameter for a cookie expiration date. Not setting the expiration will keep the cookie only for the browser session in memory. To set a permanent cookie, set an expiration date for a point in the future.

Also, note that the encryption functions handle the encryption of both the data and the key. It is important to encrypt the key as well since that can expose information about the nature of the data. For instance, if your key was "UserID", then it might be safe to assume that your encrypted value is a numeric string, giving an attacker an advantage.

Encoding Cookies

Note that our standard cookie functions encode and decode the keys and values of the cookies. The reason for this is that cookies fall under the same restrictions as URLs. Specifically, the characters '=' and ';' are reserved and must be escaped; this is especially important when saving encrypted data because the encryption algorithm will append "=" to fill the block with the allocated block size.

The Sample Project

Our sample project (zip available below) is actually two projects: EncryptingCookies and Plourdenet.Com.WebTools. EncryptingCookies is the Web-application project that contains our Web forms and utilizes the utility classes. Plourdenet.Com.WebTools is a class library project housing the utility classes. Placing the utility classes in a separate project makes it easy for us to eventually deploy the assembly to be shared with multiple Web projects.

Figure #2 - Solution Explorer for the Sample Projects

There are two thing to remember when setting up a structure like this. First, you must add a reference to System.Web in your class library. Second, you must add a reference to your utility project in your Web application. In addition, all the code that references the utility project should provide an Imports statement as such:

Imports Plourdenet.Com.WebTools

Creating Web Forms To Set Cookies

In our sample application, I have two forms. The first (and the default form) is SetCookies.aspx, and the second is GetCookies.aspx

SetCookies.aspx Web Form

The set cookies form is quite simple. We have a single text box and a button to post the value back to the server.

Figure #3 - The SetCookies.aspx Web Form

When the Save Cookie button is clicked, the form returns to the server and initiates the following server-side event:

Using a constant for the cookie key name and the value submitted in the text box, we set three cookies. First, a standard unencrypted cookie. Second, a cookie encrypted with DES, and third, a cookie encrypted with Triple DES.

GetCookies.aspx Web Form

The Get Cookies Web Form is doing a little more work behind the scene to show you what happens to your cookie data.

Figure #4 - The GetCookies.aspx Web Form

In the Page_Load event, we retrieve the cookie data using our CookieUtil accessor functions. Then, finally we dump out the contents of the entire cookie collection, just to prove there was no funny business.

So there you have it - a fairly simple yet powerful way to encrypt your cookie data. But before I leave you, I want to review a few issues to watch out for when using cookies.

Your entire cookie collection is limited to 4 kilobytes in size. This includes key, the space for key names, and other related data.

The size of your cookie data will increase when encrypted. Make sure you do not run over the limit.

Cookies are sent to the server every time a request is made to the server. Therefore, if you are lugging large cookies back and forth, you are using additional bandwidth and server processing resources.

Encrypting large amounts of data can impact application performance.

Any initial values supplied by your user cannot be encrypted unless you use SSL on your site. For instance, in our sample set cookies form, the initial value was passed in the clear to the server.

Cookies can be blocked or deleted at anytime by your users. If the use of cookies is critical to the operation of your application, you may need to find ways to work around users that can't or won't permit them.

Good Luck! And let me know when you have baked your first batch of encrypted cookies.

About the Author

Wayne Plourde is a consulting Software Architect who began his career as a building architect twenty years ago. In 1995, he succumbed to the call of the World Wide Web, and since then has been designing sophisticated Web-based and client-server applications for corporations around the country. Wayne holds both MCSD and SCJP certifications and has just completed his .NET MCAD certification. You can contact Wayne at wayne@plourdenet.com or visit his Web site at http://www.plourdenet.com.