Protecting Access program from theft

J

Jonathan Blitz

Maybe someone else has had this requirement.

We have developed a big in-house Access project.
we are worried that a disgruntled employee (end-user) would take a copy with
him/her when they left.
Last thing we need is a competitor to get a copy.

How do we protect the program so it will only run in our environment?
Some decent way of causing the program to expire would also be good.

At present there is an expiry date hard coded into the program.
Problem is that it needs updating every so often - which is a real pain.

So, any ideas?

Jonathan Blitz
CNCG Corp.
 
T

titlepusher

Here's a few tips.. But I am not a programmer.. I do alot in access and have
assembled 4 big apps. The first I did was in 2.0 and I actually coded a
security routing.. my hardest ever. First I created 2 identical files that
tracked the current date of installation and also each time that the user
executed something... mine was a report.. yours could be a form. I wanted my
users to be anble to use the app., but print nothing if not paying. Once
I had the 2 files I exported one to a .dbf and named it something like
sysconf.dbf and stuck it in the c:\windows\system subdirectory where nobody
could find it.. especially it not being an Access file. Then I linked to
that file. Now I had 2 identical files in 2 spots. To begin.. upon
installation the current date was logged into both files.. I con't rember how
I tracked the dates but if they did not match.. the system would not start.
Then in order to keep track over time I updated the # of times they printed .
You could update both files with the number of times they open the main
form. Put a number like 500 in the fileds first and count backwards to 0 as
they use it. I then had a screen that would easily allow users to add to
the number of uses available to them.. That algorithm went something like
this: take today's date and convert it to a number. Take that number and
add 63 devide it by 14.721 and then add 42, multiply by .00641 and then add
(the number of uses that you want to add (100, 250, 500 whatever.) If the
user keys that number into a field, the app. will add the appropriate number
of uses left to each of the 2 separate security files. You need to (in a
different database) write a reverse version that will give YOU the code to
enter. The user will never figure out the algorithm in a million years...
You dont need to track uses if you simply want to extend the shut-down
date... just use the date serial number instead of uses. The only trick to
making it work on remote computers is to have the dates the same.
 
L

Larry

Jonathan,

If this is a big in-house project you have hopefully separated your
application into front-end and back-end (data) databases with the front-end
database linked to the back-end. You have also hopefully created a .mde file
which is what your users execute to run your application.

This .mde file is a stripped down executable version of the .mdb file that
was originally created. It contains no code and no way to determine where
your back-end tables are linked from.

A disgruntled employee could certainly copy this .mde file and take it with
them, but if they didn't take the back-end database it would be virtually
useless to them. They would not have the source code and would not have any
tables to run against, and it would not even start up on another company's
network.

So, I would suggest that you do not give your end users access to the .mdb
file or the back-end data file. Just give them the .mde file for the
front-end.
 
J

John Vinson

Just to add to Larry's cogent comments:

The real security risk for data isn't the hacker, or the janitor, or
the disgruntled clerk. It's the Vice President who has full authority
to see the data, and who can ask for (and receive) a disk with all of
the data dumped out.

The fact that he'll be turning in his resignation and moving to a
competitor in a week is of course something that you don't get to know
until afterward.

And yes, this happened with a database that I once administered.

John W. Vinson[MVP]
 
J

Jonathan Blitz

Yes.
The users only get the runtime.

The data is stored in an SQL Server database so I suppose that that will be
enough.

Many thanks

Jonathan
 
Top