How to prevent copying?

Question

How to prevent copying?

Karim Hemani

SSCrazy

Points: 2063
More actions
September 11, 2007 at 7:33 pm

#70242

Hello,
I'm a SQL Server newbie. I'm creating a product that I intend to sell to various clients. Being in Pakistan, I am very worried about piracy issues. I know how Microsoft Access (my front-end) can be used to prevent access to the internal contents of its .mdb files. I am afraid that even if I were the DBA for all my clients, one of their employees can easily steal the physical database files and empty all the data and reuse the database afresh somewhere else. Is there any mechanism to prevent the database from being stolen? I don't trust their network admins either. Is there some way that only one person (myself in this case) can access the database and its files?
Thanks,
Karim

Viewing 5 posts - 1 through 4 (of 4 total)

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

Lowell SSC Guru Points: 323518 More actions · Answer 1

As you suspect, no there's no surefire way to prevent anyone from connecting to a database and copying the schema, nor the data. I know you probably spent a lot of time designing the database, and that time equals value to you, but unless you host the data yourself, theres no way to do it.

While you can password protect the database, the database can be opened via a brute force password, as well as other techniques.

I know in my case, if my client buys our product, it's THEIR data. If I put their data in a specific structure, they must have access to it so they can create their own reports. I just look at a table design as a work product. Some people make burgers, some people make dinners that are a work or art, but in the end, they are no longer yours once you send it out of the kitchen, so to speak.

It's the application that you should worry about being copied, and preventing from being used without some sort of autorization. There's a lot of techniques, which I'm sure you've encountered, like serial numbers, serieal numbers issued that are only good for a period of time before they must be re-generated, etc.

Lowell

--help us help you! If you post a question, make sure you include a CREATE TABLE... statement and INSERT INTO... statement into that table to give the volunteers here representative data. with your description of the problem, we can provide a tested, verifiable solution to your question! asking the question the right way gets you a tested answer the fastest way possible!

Karim Hemani SSCrazy Points: 2063 More actions · Answer 2

I appreciate it, sir. As you said, the application is very, very important and it's more important to protect the app than the database. Kindly pass me the links of any websites in your knowledge that provides tips on how to protect your app from being copied.

Karim

Antares686 SSC Guru Points: 125444 More actions · Answer 3

Most common things big companies do are give bogus names to tables and columns making it hard to figure out what the user is looking at and even encrypting some of the data at insert.

Also, you can slow them down a bit if you use SPs by using the with encryption option.

But all in all unless you sell them the hardware and you retain control if they can get to it they can get at it.

Matt Miller (4) SSC Guru Points: 124210 More actions · Answer 4

You'd probably look into obfuscation methods, and some type of hook (outside of SQL server) that would be required in order for this to app to run. It's not easy and will likely slow certain things down, involving custom encryption, etc... and OS calls to something.

in those areas - common methods for just that involve security dongles (USB or parallel devices with encrypted activation information - it needs to be detected by the system to run), or various inocuous registry keys hodling encrypted machine-specific info, etc.... You can only go so far down this path before you cripple performance so badly that noone will want to run it, though. You'd probably want to focus on "crippling" several key components using this external hook, but leave most of the other parts with standard security.

Nothing's perfect though - if it's on their premises - then they will need enough access to be able to perform maintenance, assign security, etc... Unless your application is really tight - that level access will usually give a determined SQL expert enough to find the chink in the armor and eventually "break" your security. The game then becomes - "can I make it hard enough for me to make them get bored/tired with trying to break into my stuff".

----------------------------------------------------------------------------------
Your lack of planning does not constitute an emergency on my part...unless you're my manager...or a director and above...or a really loud-spoken end-user..All right - what was my emergency again?