DB hiding/encryption

[iwease]

Hi,

I am thinking about making some useful DB packages out of code that I have worked on over the years and possibly sell them to other developers. I want to hide some code (mainly just stored procedures and some triggers).

I can do this using encyption but I hear that the encryption in SQL SErver is easily cracked. Is there another way to do this? I can't create some dll or something that is called from within a stored procedure (and hide the information in the dll)

I found this post which gave some information on the issue

http://www.tek-tips.com/viewthread.cfm?qid=1346004&page=8

 

[RiverGuy]

I'm just curious as to why you want to hide the code. I don't know many database developers or dba's who would be comfortable running database routines on a production server without knowing exactly what the routine does.

 

[iwease]

Yeah, true. But, that is the price of using third party tools. It happens all the time when developers by tools for other code. It is the same for and DB tool developer. As long as the table data remains visible, than it shouldn't matter if a tool (stored procedure) is hidden. No third party tool developer would leave their code just open to be copied or modified.

The assumption is that the tool developer has already thoroughly tested the code before distributing it.

 

[iwease]

I should mention that the code would only affect tables within the package. It would never write to other tables. And if it ever did, then perhaps that code could be left visible

 

[RiverGuy]

I do see your point, and I tend to look at third party tools for custom widgets in a 3GL language different than third party code that acts on proprietary, possibly financial databases within an organization. That being said, you might want to check into writing CLR stored procedures, and seeing if that code can be obfuscated.

 

[mrdenny]

Writing code into CRL procedures just so that people can't see the code that's being executed is a sure fire way to have people not want to purchase the tool.

We don't run any CLR code on the SQL Servers, and won't unless the DBAs can see the code to see what it's doing.

If I purchase something that will be running on a productions system I'll want to be able to see what's happening on my box, which means that I want to see the procedures. I've only seen a couple of purchased apps where the stored procedures are encrypted. I simply decrypted them so see what was going on.

Many DBAs as soon as they see that the code isn't viewable will assume that the code is suspect. If I can't see the code, I don't trust the code.

Denny
MCSA (2003) / MCDBA (SQL 2000)
MCTS (SQL 2005 / Microsoft Windows SharePoint Services 3.0: Configuration / Microsoft Office SharePoint Server 2007: Configuration)
MCITP Database Administrator (SQL 2005) / Database Developer (SQL 2005)

--Anything is possible. All it takes is a little research. (Me)

http://www.mrdenny.com

 

[SQLSister]

I'm with Denny. I would not allow anyone to run any code against my databases that I can't see. I have too much information that is private and which has legal reasons why it must be protected and I cannot certify it is protected if I can't see the code.

Questions about posting. See faq183-874

 

[iwease]

What I'm really interested in is how to hide code on SQL server. If you don't want tools with hidden code, that is fine, don't buy them. I can see that being especially important if you are dealing with highly sensitive information. But for lots of projects, 3rd party tools are fine and what I'm really looking for is some way to hide stored procedures besides encryption.