Post reply

How to secure data against DBA

  • June 16, 2005 at 10:43 pm

    #93211

    Hi,

    I am developing a typical product using .Net and sql server as backend.

    my competitor may buy my software and analyse it and prepares as of mine.

    1) Our requirement is my competitor mihgt see the database design and copy the design.

    2) I don't want let my competitor to migrate my data to his database.

    so that to prevent from above mentoined I don't want to open the database by the end user(even DBA).

    For this we have seen

    a) NetLib tool (too costly for unlimited distribution)

    b)XP_Crypt/dbEncrypt ==> which slows down the performance and needs to change the design(increasing the column size)

    How can I proceed for this.

    please guide me on this.

    Thanks & Regards

    Anji Reddy

     

  • June 17, 2005 at 2:03 am

    #566326

    You'll have to go down either path a, b, or something very similar.

    You could obfuscate your table names and do all the data retrieval and processing in your client app. This turns the database into a simple data store. This could have the added advantage of divorcing your app from a specific database vendor.

    Or, you could forget all about the encryption and obfuscation, copywrite/patent everything, then sue the pants off anyone who copies it.

    Then again, I'm a DBA, so if you were to want your encrypted application released in my environment you better be very, very ready to prove that there's no adverse performance due to any lack of database design knowledge. I've already killed off one application that the company wanted to buy, they installed a demo and a few Profiler traces later I sent the vendor packing with two pages worth of fixes they would have to make before the application could be installed in production.

     

    --------------------
    Colt 45 - the original point and click interface

  • June 17, 2005 at 9:24 am

    #566468

    There is no way to do this and the big guys, SAP, Oracle, Peoplesoft, etc. don't try.

    I can always run profiler and see which queries you send and what data is returned, encrypted or not, I can probably even build a migration plan based on this as they key will be somewhere. Either the customer has it, in which case it's easy, or it's in the code, in which case there are decompilers that will give this to me.

    The bottom line is that the app should perform and I cannot imagine that your schema or triggers, stored procedures, etc. are the basis of the application.

Viewing 3 posts - 1 through 3 (of 3 total)

You must be logged in to reply to this topic. Login to reply