Application Security Overview

Overview

I rarely find an organization who has someone whose sole job is to ensure the security of data and applications across an Enterprise.  Therefore, a lot of that job falls on the shoulders of developers.  I think security is a rather broad topic with a lot of considerations but for the purposes of this blog... I'll stick to some basic scenarios.

Really, there are two major scenarios to consider in regards to security;  the data and transport of the data.

Transport Security

The most basic and reasonable method of securing your data from point A to point B is to use a mechanism like SSL.  Normally in HTTP, data is sent in a clear text format.  Using SSL, both client and server agree on a key to use and the data is sent in an encrypted form across the wire where it is decrypted on the other end.  As you would imagine, this process does increase the size of your payload being sent and returned but prevents someone who intercepts the packets from viewing the contents without first breaking the encryption.

The performance bottleneck is one of the reasons you see merchant sites unsecured until you switch over to process a payment, at which time SSL is employed.

Data Security

When securing your data, you have options but need to choose carefully.  For example, if you encrypt data in the database that field is no longer searchable by the database engine.  Additionally, as with SSL there is the performance hit of decrypting.  Lastly, you have to consider reporting and other functionality that may have no/limited abilities to decrypt data.

Presently, Rijndael is a popular encryption algorithm and works pretty well.  You will have to specify two key values (key and IV) in order to encrypt and decrypt data.  However, both the source and destination machine must have the same keys otherwise this won't work.  A practical application of this might be to encrypt data going between two machines across the internet via a web service.  (Tho again, SSL can also be used... so Rijndael would be an added layer of protection if that was the case.)  This might also be useful when passing a token to a non-secured web service to authenticate.

On a machine, I like to use DPAPI.  This came integrated in Framework 2.0 (IE, there are objects for it you can use) and encrypts data with a key specific to the machine.  This is great for securing connection string and other components of your app or web config file.  I'm not going to go into detail but basically you can use the ProtectedData class (part of System.Security.Cryptography) with LocalMachine protection scope.

Alternately, you could do a DLLImport and use the encryption DLLs directly but this approach is frowned upon since it creates unmanaged code.

Recap

Use SSL to protect data in transit from server to client; HTTP is clear/plain text by default.
Use Rijndael to encrypt/decrypt sensitive data; remember you can't search encrypted database fields.
Use  DPAPI to encrypt data with a machine specific algorithm.