This article is written to answer following two questions I have received in last one week.

Questions 1) How to hide code of my Stored Procedure that no one can see it? 2) Our DBA has left the job and one of the function which retrieves important information is encrypted, how can we decrypt it and find original code?

Answers 1) Use WITH ENCRYPTION while creating Stored Procedure or User Defined Function. 2) Sorry, unfortunately there is no simple way to decrypt the code. Hard way is too hard to even attempt.

Explanations of WITH ENCRYPTION clause If SP or UDF are created WITH ENCRYPTION it is one way street and it is not possible to decrypt it using SQL Server commands. It is always advised to save a copy of the script used to create the SP or UDF on other media than SQL Server. There is no way to get the original source code once it is executed on Server. Only privileged users who can access system tables over the DAC port or directly access database files as well as can attach a debugger to the server process can retrieve the decrypted procedure from memory at runtime.

CLR SP and UDF can not be encrypted. SQL Server replication can not replicate encrypted SP or UDF.

I believe in fair programming techniques and strongly recommend against encryption. There should be no need to encrypt any code. If there is need to hide any code from certain users in that case user should be restricted using user login permissions.

Well, in my opinion. Instead of encrypt ur stored with FULL and CLEAR code, you need have a “key unlock” column, and a “indexed filter” column. Use “key column” with random algorithms on “indexed filter column” when you do criteria thing. Remember “RANDOM”.

In fact, due to a flaw in how SQL Server encrypts an altered procedure, decrypting the original procedure text is easy.

SQL Server uses the RC4 cipher algorithm to encrypt the procedure text. This algorithm generates a stream of key data (called the keystream) from a starting key, then encrypts the plaintext by using the XOR operation. The beauty of the XOR operation is that to reverse it, you simply XOR the ciphertext with the keystream.

Unfortunately, when you use ALTER PROCEDURE, SQL Server encrypts the new text using the same key as it did when encrypting the original text. This means it uses the same keystream. To recover the keystream when you know the ciphertext and the plaintext, you can simply XOR the ciphertext and plaintext together. You can then recover the original plaintext by XORing the recovered keystream with the original ciphertext.

There is a tool which can decrypt the encrypted stored procedure. Is there any way with which we can restrict decryption of stored procedures? In my situation the database would be in the client side and I would like to enrypt the Stored procedure. Please help.

how to protect table from viewing its data and columns in sql server 2005, we can encrypt SP’s and UDF, what abt table, i read an article on this but its for data encryption in table, but i want to encrypt table columns itself, i want to restrict the user from seeing its design

In user database set the user’s property to remove the View Definition permision on selected or all stored procedures. You can also remove the Execute permission on stored procedures. For this go to database > Security > Users > right click a user > Properties > Securables > here add object and set the permissions on that object.

Only privileged users who can access system tables over the DAC port or directly access database files as well as can attach a debugger to the server process can retrieve the decrypted procedure from memory at runtime.

Is that mean administrator can view the decrypted procedure? Is there any way to hide or prevent from retrieving the decryted script from the administrator?

I also read on some articles that there are some softwares to decrypt the encrypted SQL scripts. Can we prevent such softwares from decrypting the encrypted SQL scripts?

Hi Pinal Dave,
I understand the risk of Encrypting the sp’s, but As i am experiencing the security risk of my database as it can be easily copied to other system and get attached to another instance, I feel need of encryption. Even creating the user won’t help in these conditions.
Though i am new to MS SQL, I strongly fee that MS should incorporate the user specific database files for strong security of the database.

Hello guys,
We strongly recommend NOT to use WITH ENCRYPTION option, because as easy to encrypt, as easy to decrypt. Unfortunatelly, SQL Server uses database’s GUID and object’s ID as a key for deprecated RC4, and then simple byte-wise XOR. We hope Microsoft SQL Server’s team will eliminate this flaw or just desist support this option. As a solution we provide our FREEWARE named SQL Decryptor. Check it out on our web-site.

Well, it’s pretty easy. Run Optillect SQL Decryptor Freeware, decrypt a stored procedure you need, and copy the DDL script. Then run Microsoft SQL Server Management Studio, create new SQL editor with the same connection, paste the DDL script from the clipboard. Now remove “WITH ENCRYPTION” option, replace “CREATE” keyword with “ALTER” and execute the script. Thus you’ll get your stored procedure stored with no ecryption.
Unfortunately, SQL Decryptor v1.1 cannot do it automatically at the moment, but we are planning to support this feature in the next release.

Hi
As you said that “With Encryption” cannot be decrypted when i use alter command to modify sp without using “With Encryption” in that alter command then definitely it will remove the encryption for that sp.
This may cause Readable of stored procedure…
The code which i used for Encryption is

create proc proc123
With Encryption
As
Begin
select Title as [Name of Song],director as [Director] from videos
End
Go
—–Encryption is done here—-
*Alter proc proc123

As Begin
select * from videos
End
Go
*
—–Returned
Please give me another way to use the encryption for UDF and SP’s.

Community Initiatives

About Pinal Dave

Pinal Dave is a Pluralsight Developer Evangelist. He has authored 11 SQL Server database books, 17 Pluralsight courses and have written over 3200 articles on the database technology on his blog at a http://blog.sqlauthority.com. Along with 11+ years of hands on experience he holds a Masters of Science degree and a number of certifications, including MCTS, MCDBA and MCAD (.NET). His past work experiences include Technology Evangelist at Microsoft and Sr. Consultant at SolidQ. Follow @pinaldave
Send Author Pinal Dave
an email at pinal@sqlauthority.com

Email Subscription

Enter your email address to subscribe to this blog and receive notifications of new posts by email.