Skip to content

Encrypting T-SQL Code

November 4, 2013

This editorial was originally published on April 10, 2009. It is being re-run as Steve is on vacation.

I recently engaged in a discussion with someone that was building an application on SQL Server. This person had a bunch of SQL code that was being put in stored procedures and then being sent to client sites. The developers were worried about clients modifying their code and wanted to send “secure updates” to the client by encrypting the stored procedures and giving the clients the encrypted text.

Apart from the hassles of getting this to work, I asked by would they bother. There are decryption routines available and this isn’t meant to be a secure way to hide your code. Heck, even application code can be decompiled, and if they’re likely to mess with the code, they likely have the skills to get the source.

So for this Friday’s poll, I’m wondering about how you feel about encrypting code in SQL Server. I want to know what you think.

Is there a point?

Is there a reason to encrypt stored procedure code? After all, there are many, many vendors that sell applications built on SQL Server, with stored procedures.  Most of that code isn’t encrypted and it’s usually not a problem. Most customers don’t mess with the code and there are usually prohibitions written into support agreements.

Personally I don’t think there are many great ideas, and likely very, very few in the database space, that are worth securing. Someone doesn’t buy a software package so the can learn how you wrote it. Most of them buy software because it solves a problem and saves them time. If you can deliver a well performing, and good looking application, no one cares about the code.

But I’m curious what the rest of you think, both end users and software developers. Is there really a good reason to worry about encrypting your code?

Steve Jones


The Voice of the DBA Podcasts

Everyday Jones

The podcast feeds are available atsqlservercentral.mevio.com. Comments are definitely appreciated and wanted, and you can get feeds from there.

You can also follow Steve Jones on Twitter:

Overall RSS Feed:  or now on iTunes! 

Today’s podcast features music by Everyday Jones. No relation, but I stumbled on to them and really like the music. Support this great duo at www.everydayjones.com.

About these ads

From → Editorial

2 Comments
  1. I agree with you that, for the vast majority of cases, there is no point to encrypting your stored procedures. I’d think, however, that there are fringe cases where you have someone who thinks they are skilled enough to tinker but is very wrong. This person could accidentally alter the procedure when they simply meant to view it and run a piece of code within it or make changes that your support technicians won’t know is there until man hours have been spent on troubleshooting. Personally, I don’t think I’d put in the effort to encrypt my stored procedures since tech support personnel often have to help fix problems which were customer self-induced anyways.

  2. The support argument is fair, but people can still change things. I’d think support contracts would handle this just fine.

Comments are closed.

Follow

Get every new post delivered to your Inbox.

Join 4,301 other followers

%d bloggers like this: