Client-Side Encryption

Last week, I was pulled into an emergency meeting held by another development team in my organization.  It revolved around the need to encrypt a string on the client-side, BEFORE it was submitted to the server.

Previous to this meeting, I had been approached by one of the developers asking how to do such a thing.  I pointed him in the direction of this article on Code Project which seemed to be the way to go.  Unfortunately, members of our security team cited that only TripleDES and AES encryption can be used within our applications.

This page contains a rudimentary javascript method that performs the necessary TripleDES encryption on the client-side.  The only problem with it, though, is that the server needs to be able to decrypt the text to get at the *real* value.  That by itself, isn't the problem, though.  The *REAL* problem is that while using the same Key and IV, the javascript encryption algorithm uses different math than the .net TripleDES encryption provider.  I messed with this for quite a while, but I think it is a fundamental difference in the way that the bit flips are done in javascript vs. .Net.

In addition, I really didn't like this method because it relied upon the Key and IV to be stored CLIENT-SIDE in the javascript itself.  IMHO, if someone is going to start sniffing packets to get the encrypted information, it's just a short jump for them to figure out where the source page is, download the javascript file and get the key. 

In addition, this was something that needed to be implemented IMMEDIATELY <sigh>.  So, around midnight, that night, I went down a slightly different track.  I wrote a simple ActiveX control written in .net 1.1 that can be embedded into a page to perform the actual encryption.  It contains a few properties that can be called in javascript to set the Raw Text and then retrieve the encrypted text.  Plus, since it's .net - both the client and the server will speak the same language and the encryption/decryption works flawlessly.  The only downside is that the client MUST have .net 1.1 installed on their computer for it to work.  And, of course, it doesn't work in Firefox.  LOL...oh boy, those are 2 pretty big assumptions to make.

So I wrote a fairly verbose (kinda like this blog entry) e-mail to the folks pulled into this fool's errand, including the code for the ActiveX control and also my final recommendations.  My final recommendation was that my original (to use the RSA encryption) is the best possible method to use because it utilizes a Public and Private key.  The public key performs the encryption and the private key, the decryption.  That means you can keep the private key on the server and the public key on the client, without any reservations about keeping the public key on the client. 

I also CC'd the security team and they actually agreed with me, which was good, provided we make the key large enough.  They suggested 1,024 bits, but after doing some reading, I decided to up that to 2,048 bits because 1,024 is too easily brute forced. 

So we ended up not using the ActiveX component, I wrote, so I posted it on the files section of this site.  You can download the component AND a web project that shows how it *would* work here.

It was a productive mini-project for the simple reason that I learned a lot more about the different encryption methods available and which ones are the most secure. 

Current Mood:    Accomplished