Introduction
Every developer is exceptionally concerned about how she/he can formulate the best security of her/his SQL code object like a view / storedProcedure as well. For this reason, we will go for encryption. Encryption is a good but not utterly tenable process. In this article, I would like to show you some best practices to protect SQL server code object.
Don't Encrypt Unless Absolutely Necessary
When you distribute SQL Server-based applications to customers and other third parties, you may be tempted to encrypt the source to your stored procedures, functions, and similar objects. Obviously this protects your code from prying eyes and keeps people from making changes to your code without your knowledge.
That said, unless you have real concerns about confidential or proprietary information being stolen, I recommend against encrypting your SQL Server objects. To me, encrypting SQL Server objects is usually more trouble than it's worth. There are a number of disadvantages to encrypting the source code to SQL Server objects. Let's discuss a few of them.
One, encrypted objects cannot be scripted, even by Enterprise Manager. That is, once a procedure or function is encrypted, you cannot retrieve its source from SQL Server. The well-known but undocumented methods of decoding encrypted source in earlier versions of SQL Server no longer work, and other methods one might discover are not supported by Microsoft. To make matters worse, if you attempt to script an encrypted object via Enterprise Manager using the default options, your new script will have a DROP
statement for the object, but not a CREATE
. Instead, all you'll see is a helpful comment informing you that scripting encrypted objects isn't supported (whereas, obviously, dropping them is). If you run this script, your object will be lost. It will be dropped, but not recreated.
Two, encrypted objects cannot be published as part of a SQL Server replication. If your customers set up replication operations to keep multiple servers in synch, they'll run into problems if you encrypt your code.
Three, you can't check encrypted source code for version info (such as that inserted by a source code management system). Because customers can load backups that may reinstall an older version of your code over a newer one, it's extremely handy to be able to check the code for version info on the customer's server. If your code is encrypted, you can't easily do this. If it's not, and if you've included version information in the source code, you should be able to easily determine the exact version of an object the customer is using.
How Do I Protect My Stored Procedure Code?
When deploying applications to a client's server(s) or to a shared SQL Server, there is often a concern that other people might peek at your business logic. Since often the code in a stored procedure can be proprietary, it is understandable that we might want to protect our T-SQL work. There is a trivial way to do this in SQL Server, instead of:
CREATE PROCEDURE dbo.Example
AS
BEGIN
SELECT 'SQL statements'
END
GO
You can use the WITH ENCRYPTION
option:
CREATE PROCEDURE dbo.Example
WITH ENCRYPTION
AS
BEGIN
SELECT 'SQL statements'
END
Now, before you do this, make sure you keep the logic of the stored procedure in a safe place, since you won't have easy access to the procedure's code once you've saved it.
Now you will notice that when you try to open the procedure in Enterprise Manager's GUI, you will receive the following error:
Microsoft SQL-DMO
Error 20585: [SQL-DMO]
/******
Encrypted object is not transferable,
and script can not be generated.
******/
And when you try to use sp_helptext
to review the code...
EXEC sp_helptext 'Example'
... you will get the following error:
The object comments have been encrypted.
Unfortunately, there are at least two ways to defeat this mechanism. One is to run SQL Profiler while executing the stored procedure; this often can reveal the text of the procedure itself, depending on what the stored procedure does (e.g. if it has GO batches, dynamic SQL, etc.). If they miss the initial install, the user can delete the stored procedures or drop the database, start a Profiler trace, and ask you to re-create them (in which case they will capture the CREATE PROCEDURE
statements). You can prevent Profiler from revealing the text to snoopers by embedding sp_password
in the code, as a comment:
CREATE PROCEDURE dbo.Example
WITH ENCRYPTION
AS
BEGIN
SELECT 'SQL statements'
END
References
For more about this topic can be found at this link.
Conclusion
I hope that this article might be helpful to you. Enjoy!
History
- 30th July, 2009: Initial post