I'm putting together a sql update script execution application and one concern is that someone could grab the script during execution by having a sql trace running. After checking out the sql server documentation, I came across the following select statement:
select * from :: fn_trace_getinfo(default)
If one or more rows are returned, at least one trace is being run on the system. Cool stuff!
This has been the one caveat to securing the process. I'm using the SharpZipLib to compress the script before using TripleDESServiceProvider class to provide encryption. As a test, I reversed the process to see how much repetition would appear in an uncompressed script. Here are my numbers:
Script File Size = 3.9MB
Encryped File Size = 3.8MB
Encrypted then Zipped File Size = ~<3.8MB
Zipped File Size = 370000 bytes
Zipped then Encrypted File Size = 369000 bytes
I found it interesting that the encryption creates a random enough pattern to the data that compression doesn't work well.
I've read that compressing a file before encrypting is supposed to be more secure because it makes cracking the encryption. I imagine this could be true since it introduces another step that must be discovered in the process of hacking the file, however I wonder if it would be easier to hack since you'd know what the zip header has to look like.