How to prevent database to be copied

  • Thread starter Thread starter Gilbert Campo
  • Start date Start date
G

Gilbert Campo

I have a database that I want to protect against un-authorized use and
copying. Any suggestions?
 
Unless there's something available at the Windows Server/Group Policy/User
Account level, you can't prevent a person who can see a file from copying it.
You can, however, make it more difficult by first ensuring that only the
people who should have access to the file have rights to it via the Groups
that have access to the folder. You have to maintain Read/Write access in
order for Access to be able to work with the contained data. You can also
make the file and the folder hidden so that even those that have Group
permissions to the folder and file can't see it.

Keep in mind, that there's nothing from stopping one of this persons from
going in and manually copying the file or connecting to the database.

Of course you can still implement Access security, but it sounds like in
your situation you need to start with the User Permissions. You'll need to
get in touch with someone that has Administrator rights on the server.
 
Unless there's something available at the Windows Server/Group Policy/User
Account level, you can't prevent a person who can see a file from copying it.
You can, however, make it more difficult by first ensuring that only the
people who should have access to the file have rights to it via the Groups
that have access to the folder. You have to maintain Read/Write access in
order for Access to be able to work with the contained data. You can also
make the file and the folder hidden so that even those that have Group
permissions to the folder and file can't see it.

Keep in mind, that there's nothing from stopping one of this persons from
going in and manually copying the file or connecting to the database.

Of course you can still implement Access security, but it sounds like in
your situation you need to start with the User Permissions. You'll need to
get in touch with someone that has Administrator rights on the server.
 
Its more along the lines of putting up roadblocks as opposed to flat saying
you can't copy it.
 
Its more along the lines of putting up roadblocks as opposed to flat saying
you can't copy it.
 
Gilbert Campo said:
I have a database that I want to protect against un-authorized use and
copying. Any suggestions?
Click to expand...

Can't be done. All you can do is obfuscate the location a bit. But a
person with some computer experience can get past that in about 15
seconds.

Make your FE an MDE and that will help quite a bit as folks won't be
able to see the code. Other than MDE to MDB Conversion Service for
Microsoft® Access
http://www.everythingaccess.com/mdeconversion.htm

Tools available from sites such as sysinternals.com can crack any
method you use to store a future date anywhere on a system such as in
the registry or a file. Unless it's encrypted. But even then if you
delete the date from wherever it's stored your app may think it's just
installed.

Thus I prefer to limit the number of records in one key table such as
5 units or 50 volunteers but allow unlimited access for everything
else. Once I get paid then I email them an encrypted file containing
the number of records they are licensed for as well as their company
name which goes on the bottom of every page of every report and
frequently used forms.

For more of my thoughts on this topic see the "Copy protection or how
to safely distribute a demo Microsoft Access Application" page at
http://www.granite.ab.ca/access/demo.htm

Tony
 
Gilbert Campo said:
I have a database that I want to protect against un-authorized use and
copying. Any suggestions?
Click to expand...

Can't be done. All you can do is obfuscate the location a bit. But a
person with some computer experience can get past that in about 15
seconds.

Make your FE an MDE and that will help quite a bit as folks won't be
able to see the code. Other than MDE to MDB Conversion Service for
Microsoft® Access
http://www.everythingaccess.com/mdeconversion.htm

Tools available from sites such as sysinternals.com can crack any
method you use to store a future date anywhere on a system such as in
the registry or a file. Unless it's encrypted. But even then if you
delete the date from wherever it's stored your app may think it's just
installed.

Thus I prefer to limit the number of records in one key table such as
5 units or 50 volunteers but allow unlimited access for everything
else. Once I get paid then I email them an encrypted file containing
the number of records they are licensed for as well as their company
name which goes on the bottom of every page of every report and
frequently used forms.

For more of my thoughts on this topic see the "Copy protection or how
to safely distribute a demo Microsoft Access Application" page at
http://www.granite.ab.ca/access/demo.htm

Tony
 
Have you thought about using a custom database property(ies) that have a
name/value pair that's deceptive in its name such as 'Release Version' and
then change the value in such a way to indicate that the version is now
licensed as in...

Version Date: 4/10/2009
Release Version 4.01.1

Version Date: 4/10/2009
Release Version 4.1.1

Version Date contains the information used to indicate the real version
that's being run for upgrade purposes.
Release Version contains the necessary information to determine if its
licensed. The subtle difference being that the second value is 01 if its not
licensed 1 if it is. Anyone looking at the value before/after the license key
is applied probably won't notice it or place any value on the difference if
they do. Not to mention that the person isn't likely to look at the database
properties to begin with.
 
Have you thought about using a custom database property(ies) that have a
name/value pair that's deceptive in its name such as 'Release Version' and
then change the value in such a way to indicate that the version is now
licensed as in...

Version Date: 4/10/2009
Release Version 4.01.1

Version Date: 4/10/2009
Release Version 4.1.1

Version Date contains the information used to indicate the real version
that's being run for upgrade purposes.
Release Version contains the necessary information to determine if its
licensed. The subtle difference being that the second value is 01 if its not
licensed 1 if it is. Anyone looking at the value before/after the license key
is applied probably won't notice it or place any value on the difference if
they do. Not to mention that the person isn't likely to look at the database
properties to begin with.
 
David H said:
Have you thought about using a custom database property(ies) that have a
name/value pair that's deceptive in its name such as 'Release Version' and
then change the value in such a way to indicate that the version is now
licensed as in...

Version Date: 4/10/2009
Release Version 4.01.1

Version Date: 4/10/2009
Release Version 4.1.1

Version Date contains the information used to indicate the real version
that's being run for upgrade purposes.
Release Version contains the necessary information to determine if its
licensed. The subtle difference being that the second value is 01 if its not
licensed 1 if it is. Anyone looking at the value before/after the license key
is applied probably won't notice it or place any value on the difference if
they do. Not to mention that the person isn't likely to look at the database
properties to begin with.
Click to expand...

Yes, but

1) I don't like security by obfuscation. Once the secret is out then
you have big problems.

2) In the Granite Fleet Manager program I don't care if they use the
demo system for five years. They just can't enter or use more than
five units.

3) I'm quite irritated by programs that have a 30 day trial. Because
inevitably I take a look at it, look at some competitors and, 45 days
go by, when I'm ready to take a second detailed look at the program.

Tony
 
David H said:
Have you thought about using a custom database property(ies) that have a
name/value pair that's deceptive in its name such as 'Release Version' and
then change the value in such a way to indicate that the version is now
licensed as in...

Version Date: 4/10/2009
Release Version 4.01.1

Version Date: 4/10/2009
Release Version 4.1.1

Version Date contains the information used to indicate the real version
that's being run for upgrade purposes.
Release Version contains the necessary information to determine if its
licensed. The subtle difference being that the second value is 01 if its not
licensed 1 if it is. Anyone looking at the value before/after the license key
is applied probably won't notice it or place any value on the difference if
they do. Not to mention that the person isn't likely to look at the database
properties to begin with.
Click to expand...

Yes, but

1) I don't like security by obfuscation. Once the secret is out then
you have big problems.

2) In the Granite Fleet Manager program I don't care if they use the
demo system for five years. They just can't enter or use more than
five units.

3) I'm quite irritated by programs that have a 30 day trial. Because
inevitably I take a look at it, look at some competitors and, 45 days
go by, when I'm ready to take a second detailed look at the program.

Tony
 
So what do you think about using a key that embeds within itself the
calculation for a value which indicates that the product is licensed or not?

For example, in the following key the ASCII value of the 3rd character
indicates the value that the sums of every fourth character should equal (I
chose the 3rd/4th character randomly.)

FBMDx-xxxIx-xxxVx-xxxVx-xxxGx

Position 1 - Character whose ASCII number indicates the number of key
control numbers (6)
Position 3 - Character whose ASCII number represents the sum of the key
control numbers (77)
Position 4 - Character whose ASCII number represents the location of the key
control numbers at every interval (4)

In the situation above, the code that validates the key would loop back
through the string to obtain the 6th value.
 
So what do you think about using a key that embeds within itself the
calculation for a value which indicates that the product is licensed or not?

For example, in the following key the ASCII value of the 3rd character
indicates the value that the sums of every fourth character should equal (I
chose the 3rd/4th character randomly.)

FBMDx-xxxIx-xxxVx-xxxVx-xxxGx

Position 1 - Character whose ASCII number indicates the number of key
control numbers (6)
Position 3 - Character whose ASCII number represents the sum of the key
control numbers (77)
Position 4 - Character whose ASCII number represents the location of the key
control numbers at every interval (4)

In the situation above, the code that validates the key would loop back
through the string to obtain the 6th value.
 
Gilbert,

We have a product that provides copy protection for Access
applications. It uses hardware ID numbers on the end user's computer
to act as a sort of software dongle. It's called KeyedAccess and you
can download a demo from http://www.peterssoftware.com/ka.htm

There's also SageKey Application Security that does something similar:
http://www.sagekey.com/security_details.aspx

Hope this helps,

Peter De Baets
Peter's Software - Microsoft Access Tools for Developers
http://www.peterssoftware.com
 
Gilbert,

We have a product that provides copy protection for Access
applications. It uses hardware ID numbers on the end user's computer
to act as a sort of software dongle. It's called KeyedAccess and you
can download a demo from http://www.peterssoftware.com/ka.htm

There's also SageKey Application Security that does something similar:
http://www.sagekey.com/security_details.aspx

Hope this helps,

Peter De Baets
Peter's Software - Microsoft Access Tools for Developers
http://www.peterssoftware.com
 
David H said:
So what do you think about using a key that embeds within itself the
calculation for a value which indicates that the product is licensed or not?
Click to expand...

The details don't matter and you're getting a bit detailed here. My
point is to not use any kind of date expiry but use a different means
of limiting the usefulness of your software. In my opinion limiting
the number of records in a main table is a good solution for database
apps. Supply the user with some kind of method to exceed a minimum
number of demo units is one logical answer.

Tony
 
David H said:
So what do you think about using a key that embeds within itself the
calculation for a value which indicates that the product is licensed or not?
Click to expand...

The details don't matter and you're getting a bit detailed here. My
point is to not use any kind of date expiry but use a different means
of limiting the usefulness of your software. In my opinion limiting
the number of records in a main table is a good solution for database
apps. Supply the user with some kind of method to exceed a minimum
number of demo units is one logical answer.

Tony
 
We have a product that provides copy protection for Access
applications. It uses hardware ID numbers on the end user's computer
to act as a sort of software dongle. It's called KeyedAccess and you
can download a demo from http://www.peterssoftware.com/ka.htm

There's also SageKey Application Security that does something similar:
http://www.sagekey.com/security_details.aspx
Click to expand...

I'm not a fan of those because if the user legitimately moves the app
to another system then they have to ask you to unlock the app. And
if you go out of business then the customer has even more troubles
when their PC dies.

Still it is a solution.

Tony
 
We have a product that provides copy protection for Access
applications. It uses hardware ID numbers on the end user's computer
to act as a sort of software dongle. It's called KeyedAccess and you
can download a demo from http://www.peterssoftware.com/ka.htm

There's also SageKey Application Security that does something similar:
http://www.sagekey.com/security_details.aspx
Click to expand...

I'm not a fan of those because if the user legitimately moves the app
to another system then they have to ask you to unlock the app. And
if you go out of business then the customer has even more troubles
when their PC dies.

Still it is a solution.

Tony
 
Tony said:
I'm not a fan of those because if the user legitimately moves the app
to another system then they have to ask you tounlockthe app.  
Click to expand...

Yes, that's true. But I had the same issue with my copy of Quicken
(tm). I'm sure other major applications function this way.
And
if you go out of business then the customer has even more troubles
when their PC dies.
Click to expand...

Well, a backup of the install and data files on CD should ameliorate
this issue. And wouldn't this issue also crop up with your records
limitation solution?

Regards,

Peter De Baets
http://www.peterssoftware.com
 
Back
Top