|
|
|
SSC-Addicted
 
Group: General Forum Members
Last Login: Monday, March 01, 2010 7:20 AM
Points: 458,
Visits: 555
|
|
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.
---------------------------------------------
Nothing is impossible.
It is just a matter of time and money.
|
|
|
|
|
SSChampion
Group: Administrators
Last Login: Today @ 1:33 PM
Points: 23,148,
Visits: 6,911
|
|
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.
|
|
|
|
|
SSC Journeyman
Group: General Forum Members
Last Login: Friday, March 12, 2010 2:54 PM
Points: 81,
Visits: 159
|
|
| 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.
|
|
|
|
|
SSC Rookie
Group: General Forum Members
Last Login: 2 days ago @ 11:19 AM
Points: 27,
Visits: 75
|
|
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.
|
|
|
|
|
Forum Newbie
Group: General Forum Members
Last Login: 2 days ago @ 5:27 AM
Points: 8,
Visits: 175
|
|
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).
|
|
|
|
|
Forum Newbie
Group: General Forum Members
Last Login: Monday, May 11, 2009 5:49 PM
Points: 4,
Visits: 4
|
|
| 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.
|
|
|
|
