Encryption SQL Server 2005

Question

I have a SQL Server 2005 Database and I am planning to encrypt some of my columns using PassByPhrase. But these columns have to be displayed in the original form on my ASP.Net web pages and on some Crystal Reports. Now I know that I will have to create a Stored Procedure to decrypt the columns and run this stored procedure every time my classes (which display the data) hit the database. But if I store my passphrase in some stored procedure, then anybody who has access to the database can open the stored procedure and get the value of the pass phrase. Then what's the point of encryption?

So my questions are:

1. How would I display my Encrypted columns(in their original form) on a ASP webpage or a Crystal Report?

2. How should I store my Passphrase?

Answer 1

There is no magic bullet. the problem you see is always there when a service has to access data on an user behalf. Encryption is not a substitute for access protection. If you need to display encrypted data then you must present the decryption key. There are only two possibilities:

1. you ask the user for the password. The user enters the password (in web, or in crystal) and then you use the password to decrypt data. this works perfectly if the user wants to protect the data against you . Data is protected cryptographycally, even users that do have read access to the data still cannot decrypt the data w/o knowing the password. Is also basically impossible to implement in practice.
2. you store the encryption key in a key hierarchy (symmetric key->certificate->master key->service master key) ultimately rooted in the service master key, therefore in the OS DPAPI. See Encryption Hierarchy . This gives access to decryption key to the SQL Server service itself and therefore any user with access to the server can decrypt the data by simply asking the server to decrypt it for him. While on the server, the data is protected only by access protection (grant/deny/revoke SELECT permissions). However the data is protected against accidental media loss, which is often the true requirement anyway. This is often used as a poor man solution when licensing does not allow for TDE .

That's all there is. Anything else is either a variation on the encryption hierarchy theme (eg. storing passwords in ASP.Net config files under protected sections) or plain old snake oil (like embedding passwords in app code).