April 13, 2009 at 8:09 am
I wish the encryption worked. The current implementation is a joke and as such is useless. I think there are many cases when one would like or must encrypt the code.
Most of mine applications have 80% to 90% of their business logic in the database so having the stored procedures encrypted would greatly help if I wanted the IP protected.
In my opinion the problem is not why you need it but why it is implemented in such a way that any smart kid can brake it in 5 minutes.
---------------------------------------------
[font="Verdana"]Nothing is impossible.
It is just a matter of time and money.[/font]
April 13, 2009 at 10:22 am
I'm not sure encryption ever protects IP. If the computer needs to execute it, someone can decompile it. Those rules are well understood, and IP protection is usually through the legal system.
April 13, 2009 at 10:47 am
My company has a goverment contract and must meet the DIACAP(DOD Information Assurance Certification and Acreditation Process) standards. These require that all non-vendor stored procedures and views must be encrypted. So, some times, you have no choice in the matter.
April 13, 2009 at 11:56 am
For me, the consideration to encrypt anything at the database level comes down to who owns the data. Certain information a client should have access to while other areas they shouldn't. Any information that I personally enter into the program I should have access to see and manipulate for my own purposes. Addresses and contacts would be a great example of this. By encrypting everything, you are forcing the user to have to enter their address information in all over again even if that information exists in another source. By allowing them to have access to it, they can write their own import routines even though you haven't explicitly defined that functioanlity in code. Likewise, any information that is considered proprietary the user should not be able to see. For example, as other posts mentioned, company IP addresses, database usernames/passwords, smtp address information or any information stored in tables that are considered proprietary information.
As a developer, I know often times when I'm using a program, I state to myself I wish that the program could just do XYZ. By letting me have access to my own information and non proprietary information, I can implement those changes myself, which may actually keep me using the prroduct to begin with. If I wasn't able to make some minor changes, then I'd probably switch software packaages to find the feature.
April 13, 2009 at 12:08 pm
michael.wiles (4/13/2009)
For me, the consideration to encrypt anything at the database level comes down to who owns the data. Certain information a client should have access to while other areas they shouldn't. Any information that I personally enter into the program I should have access to see and manipulate for my own purposes. Addresses and contacts would be a great example of this. By encrypting everything, you are forcing the user to have to enter their address information in all over again even if that information exists in another source. By allowing them to have access to it, they can write their own import routines even though you haven't explicitly defined that functioanlity in code. Likewise, any information that is considered proprietary the user should not be able to see. For example, as other posts mentioned, company IP addresses, database usernames/passwords, smtp address information or any information stored in tables that are considered proprietary information.As a developer, I know often times when I'm using a program, I state to myself I wish that the program could just do XYZ. By letting me have access to my own information and non proprietary information, I can implement those changes myself, which may actually keep me using the prroduct to begin with. If I wasn't able to make some minor changes, then I'd probably switch software packaages to find the feature.
If the database you are referring to doesn't have a real application with real auditing and business rules, then YES you should/could be able to do whatever you want to the data. If it is a mission critical database with a real app and real business rules with some sort of audit trail as to who made changes, when, and under the business rules, then NO you shouldn't have that kind of access to it even if it is your data. This may be over simplified, but just something to think about. I have gotten many requests over the yrs to do "data fixes" and very early on I recognized the value of pushing back pretty hard on these explaining to users, managers, directors that if I do the data fix, they lose all auditability of those changes (if it was present in the first place).
April 13, 2009 at 4:01 pm
Encrypting the stored procedures is something that I have been looking forward to implement on our products, unfortunately with SQL Server, it is really no point in doing so as most of us already aware that you can easily decrypt them. I do agree that it is still the first level of protection, but until versioning is possible in SQL Server. Otherwise this will add burden to the person doing the support. In my wish-list, I am looking forward toward a “versioned” encrypt able procedures. As in most products, each of customers may implement a different version of procedures; therefore it is important for the support person knowing what they are troubleshooting. Yes, it adds complexity in troubleshooting but it is another form of protecting the codes from direct competitors nowadays.
November 4, 2013 at 12:48 am
Working on both (vendor and client production) side I would see proper encryption of the whole database (data & code) being a better way forward than obscuring the stored procedures.
On the vendor side design is often over complicated because of the view of stopping the client from playing.
On the production side, an un-tuned database to some is too irresistible, to others "I can do that better..." creates too many issues, including the day that the vendor goes "that's' not our code, this is going to cost you $£$£ for us to go through all the code to see what else is wrong, before we admit to any of our code/design is wrong" Siebel/SAP/MS/Oracle...
If the database was fully secured even from a few performance counters/Diagnostics tools then it would be simple to say to the vendor "The performance/diagnostics is too poor, you will *not*get paid until its better. Your move.." Seen this from both sides.
November 4, 2013 at 8:03 am
I believe that the client or customer should own their data and the basic means to access the data. They should have a sysadmin account. If your application has some proprietary algorithms that you would not want reverse engineered, then you could leverage something like a web service call and dynamic code execution, thus avoiding the need to embed or persist it within the client side executable modules or database.
http://srinibytes.blogspot.com/2010/04/dynamic-code-execution-in-c.html
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
November 4, 2013 at 9:10 am
At our company, we have thousands of SQL instances (with more databases than I can think about without some Advil). We have some core/centralized DBA groups, but then we have some decentralized DBA support (because of acquisitions and other internal political situations). Our core/central group has written some monitoring, collection, and general maintenance procs that we want to be "the same" on all servers. Unfortunately, sometimes our decentralized DBAs take it upon themselves to "tweak" the procs for various reasons and don't let us know they have a need for the "tweak". We thought about managing the code by encrypting, compiling, and even brute force just re-pushing the code out to all instances periodically. We do not care at all if they "see" and understand the code, we just want them to not change it. Wondering if anybody has any thoughts on this angle?
November 4, 2013 at 9:44 am
tdietrich (11/4/2013)
At our company, we have thousands of SQL instances (with more databases than I can think about without some Advil). We have some core/centralized DBA groups, but then we have some decentralized DBA support (because of acquisitions and other internal political situations). Our core/central group has written some monitoring, collection, and general maintenance procs that we want to be "the same" on all servers. Unfortunately, sometimes our decentralized DBAs take it upon themselves to "tweak" the procs for various reasons and don't let us know they have a need for the "tweak". We thought about managing the code by encrypting, compiling, and even brute force just re-pushing the code out to all instances periodically. We do not care at all if they "see" and understand the code, we just want them to not change it. Wondering if anybody has any thoughts on this angle?
If the DBA is a member of sysadmin role, not just db_owner, then you can't deny permissions to them. However, features like foreign keys or replication will enforce certain constraints on how and when the schema of an object can be altered. Replicating these stored procedures using a publication / subscriber model (merge replication) could solve two problems: how to seamlessly publish object changes to multiple subscribers and also how to prevent the DBA from altering those objects that are subscriptions.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
Viewing 10 posts - 61 through 69 (of 69 total)
You must be logged in to reply to this topic. Login to reply