Protecting Proprietary SQL code
-
quote:
Um, please tell me what the name of your product will be or is so I can avoid it like the plague.....no matter how paranoid YOU are about having your code copied......#1 is, you aren't perfect, and your product will probably fail somewhere in production....cursing the day you were born ...it's a royal pain in the arse.
nice...I'll have to add death by flame to the list of the downsides of taking this approach.
-
quote:
If you do this, you're intentionally limiting the performance of your app, are you not? You're going to place additional load on the middle layer. You're going to create more network traffic than what is necessary.not if the alternative is to pull back large amounts of data accross the network then process it on the middle tier, and write back the results to the database - iteratively.
The decision to implement commercially sensitive logic in components rather than a database is a decision I think a lot of comapnies make, even if it would be more efficient to put it SPs...what I'm trying to do is identify a good way to do this on the DB that would provide a similar level of protection as the alternative
However your arguments are quite compelling, adding decoy code does seem a bit drastic and not an option appropriate in most scenarios.
But in cases such as analytical applications where large amounts of data are processed, I still think this is a technique that could be considered as I believe it could make accessing commercially sensitive logic a lot more difficult than simple obfuscation....
-
Speaking of decoy code. You could easily write several SPs that do basic tasks like INSERTS, UPDATES, DELETES, and SELECTS on small tables and even on large tables pulling a ROLLBACK TRANS to make it look like a failed transaction or doing a RAISERORR with phoney validation (but then you have to handle the error in your app).
But I was thinking along the line s of simple get this value and write to this small table with a simple clustered index then truncate it making it look like a support table. But on the client side using ADO with the adExecuteNoRecords to avoid a bit of the network traffic. This effectively gives a dummy process they cannot figure out. In these tables use real names with obfuscated looking values (kinda like an after thought) and throw in the data the client version, and originating IP. Things that immediately look familiar and will catch their attention.
More or less like an illusionist, get them to look at one hand while the other is busy making magic.
-
No argument on pulling the data back from the databaseand processing it at the middle tier. My only concern from a performance perspective are the decoys. You've indicated that these would fire at non-critical times... however defining that may be tough.
K. Brian Kelley
http://www.truthsolutions.com/
Author: Start to Finish Guide to SQL Server Performance Monitoring
http://www.netimpress.com/shop/product.asp?ProductID=NI-SQL1
K. Brian Kelley
@kbriankelley -
quote:
Also, consider if you use non-sensical names, the people you punish most are your developers. The main reason we have variables, functions, and other programming constructs with rational names is because we've seen the other side and the grass isn't greener. I remember trying to track what B$ and D$....I forgot to reply to this good point last time....what I had in mind for the obfiscation was a script or tool that could be run as part of the build process, so the well structured, documented and standardised code in your source control database is still fully mantainable, but it gets obfuscated when built for distribution...
-
quote:
More or less like an illusionist, get them to look at one hand while the other is busy making magic.yeah I think there's all sorts of ways to improve the defense using decoy code withhout neccessarily affecting performance too much,...its just a case of generating the code in such a way that (as you've suggested) makes it look real but doesn't cause too much extra processing or traffic...a challenge, but I think its doable.
-
I notice that Microsoft haven't encrypted the build in stored procedures within SQL Server!
Ripping off the SQL code is only practical if you rip off the database schema as well.
I would say that the majority of stored procedures are for carrying out fairly basic tasks in any case and therefore I wouldn't bother encrypting them. I would be more worried about protecting the data from unauthorised access.
I can understand wanting to protect your app from competitors, but unless you have built the worlds first perfect admin program the surely your user admin documentation reveals quite a bit about how your program works?
If someone has SA access then it is very hard(impossible) to block unauthorised access. Try http://www.lostpasswords.com to see how easily passwords can be decrypted!
-
Brandon,
I still belive that this is the wrong way you go by doing as you have written (remove comments, table, sp names...) (bonjour la maintenance!
)The same with the profiler. I am supporting some several thousends of users within several dozen of databases. I run the profiler every day. to check performance issues etc.
I would really hate a program which would stop executing on 2000 clients just because I do my daily job!
If you want to protect your code and you have time to do you can create extended stored procedures. So you can deliver jus the DLLs register them and use them.
So even in the profiler the only thing the user will see is a ver nice SP name like: pxp_ThisIsMyStoredProcCalculatingTheTaxes
Bye
Gabor -
quote:
I remember trying to track what B$ and D$ wereSoftware dating yourself there too Brian(or should I say old codger?)...
As to obscuring the sql code, it will make it much harder to manage and release.
Things like the SQL Debugger, SQL Profiler, and SQL-Compare will discontinue to
function. I am all for security, but often times you can do more harm than good
by being paranoid. As an aside you should be more careful with things that get
dropped onto the client machines, as these things are readily available. Not too
long ago I came across a developer who was in the habit of hard coding
connection strings into his VB code. After I showed him that with the highly
sophisticated hacker tool "Notepad", I could read those connection strings from
his compiled binary, he stopped doing so. (At least I hope so) I retrieved for
him the server name, user name, and password he used for a client to connect to
one of their oracle servers from a dll he wrote. If you have something capable
of doing a unicode search, then search your system for files containing the word
: "Provider" in files of type "*.dll;*.exe;*.ocx". Securing code on your server
may seem like a good idea, but make sure you don't have any beams in your code
before removing the toothpick from the server.
Tim C.
//Will write code for food
Tim C //Will code for food -
I see the embedded connection string all the time, truly horrible. At least obscure it!
Andy
-
We use a tool called dbLockdown to encrypt all database objects. It will encrypt all database object scripts for stored procedures, triggers, user defined functions and views in our shipping MSDE databases and customer SQL Server databases.
The product automates the insertion of WITH ENCRYPTION for one or more database objects and handles all the archiving and restoration of database objects - since it is (natively) a one-way encryption. The encryption is hackable - with the right tool. However, our philosophy is that it's still a _deterrent_ and, in most cases, will protect valuable T-SQL code.
Eval of dbLockdown is available at http://www.ecatenate.com/dblockdown_downloads.html if you're interested.
-
If you don't hard code your connection strings and you don't use NT security then what do you do?
-
What I would do and have been doing is store the string in encypted text using 3DES with CAPICOM.dll from MS which is free. The reason for not storing easy to read connection strings is that String constants in almost all programming languages are visible thru notepad or other text editor. So as for VB
Const myConn = "Provider=SQLOLEDB.1;Initial Catalog=dbx;SERVER=localhost"
looks in notepad like this with the compiled app.
P r o v i d e r = S Q L O L E D B . 1 ; I n i t i a l C a t a l o g = p P r o v i d e r = S Q L O L E D B . 1 ; I n i t i a l C a t a l o g = d b x ; S E R V E R = l o c a l h o s t
so it is easy to find. Encrypt it with an odd character password like this
"l£f[fÁSfHZfuSfTfUfÔ¤f¬CfWÓfýZfwâfy¥fXf"
(the previous string came from the compiled version of the VB app's encrypted section. So this looks like a normally encrypted piece and not a constant, fooling the casual intruder.)
To make improbable to be found by casual looking and don't use variables with names like myConnection which in memory could be spied.
For more details on CAPICOM see http://msdn.microsoft.com/library/default.asp?url=/library/en-us/security/security/getting_ready_to_use_capicom.asp and http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnsecure/html/intcapicom.asp
-
Right now I just obscure them, but they are in the executable. Working on a solution that stores them serverside and encrypted, app pulls what it needs and decrypts. Not done yet, keeps getting pushed down the list.
Andy
-
Have you ever considered storing them encrypted in the registry?
)
Viewing 15 posts - 31 through 45 (of 50 total)
You must be logged in to reply to this topic. Login to reply