Alternatives to MDE for security

[d_lwl]

We have created an Access 2002 Application which refuse to be compiled,
the option is greyed out. The application runs fine as a MDB. From
searching through online references we learned that the MDE creation
process can be easily broken, and that a compiled MDE can be decompiled
from tools available from the net.

Without going through the troubles of setting up user level security,
can people help suggest what other simple security provisions are
useful? We are planning to disable shift-enter DB startup, as well as
the use of shift-F11.

Thanks for sharing your insights.

David

 

[Albert D. Kallal]

A mde is far and away the best bet for securing your code.

The user level security is not that strong, and certainly MUCH easier to
break then mde.

We have created an Access 2002 Application which refuse to be compiled,
the option is greyed out.

If the option is grayed out, then likey your mdb file is in a2000 format
(this is the
default for a2000, a2002, and a2003. This default was choosen for reasons
of maximuin compatiablity. So, convert your a2000 mdb to a2002, and then
you should have no problems creating the mde. As for the compiling part,
you just while looking at code go debug->compile. You must be able to
compile BEFORE you actually attempt to create the mde. So, dispite
you not having the make mde otpion (due to your mdb being in the
wrong format), you can *still* comple your code now.

The application runs fine as a MDB. From
searching through online references we learned that the MDE creation
process can be easily broken, and that a compiled MDE can be decompiled
from tools available from the net.

I see a few tools advertised out there, but they are rare, and do have
limtaitons.

Without going through the troubles of setting up user level security,
can people help suggest what other simple security provisions are
useful? We are planning to disable shift-enter DB startup, as well as
the use of shift-F11.

You most certainly can, and should hide all of the ms-access interface. The
options to complete hide and keep people out of the ms-access interface can
easily be done using the tools->start-up options. Using those options allows
you to complete hide the ms-access interface (tool bars, database window
etc). Also, using these options means you
do not have to bother setting up security. (in my opinion, it is far easier
to have ULS security broken then that of de-compiling a mde).

Try downloading and running the 3rd example at my following web site that
shows a hidden ms-access interface, and NO CODE is required to do
this....but just some settings in the start-up.

Check out:

http://www.members.shaw.ca/AlbertKallal/msaccess/DownLoad.htm

After you try the application, you can exit, and then re-load the
application, but hold down the shift key to by-pass the start-up options. If
want, you can even disable the shift key by pass. I have a sample mdb file
that will let you "set" the shift key bypass on any application you want.
You can get this at:
http://www.members.shaw.ca/AlbertKallal/msaccess/msaccess.html

If you convert the above sample to a mde, you have a application with a
hidden interface, and quite well locked up.

 

[Brendan Reynolds]

If it is your source code that you are worried about, FMS have a product
that, among other things, can 'obfuscate' your source code, so that even if
someone did get access to the source code, it would be much more difficult
to decipher. I have not personally used this feature, so can't comment any
further on it, but I believe they have a trial version available ...

http://www.fmsinc.com/Products/CodeTools/index.html

 

[Guest]

Hi Albert,

I've had a look at your shift key bypass routine and it looks just great.

Is the idea to use that form as the Startup form and how does the creator
enter the database to make amendments?

Regards:
Anthony Judge

 

[Albert D. Kallal]

Hi Albert,

I've had a look at your shift key bypass routine and it looks just great.

Is the idea to use that form as the Startup form and how does the creator
enter the database to make amendments?

The creator works on the mdb, and then when ready to deploy, you create the
mde, and the user(s) get that.

So, in effect, your production version never has the shfitkey set anyway....

Of course, during development, you will hold down the shift key so your
start-up settings don't run. You then develop for awhile, and then to test
in
"user" mode, you exit..and then re-enter the application without the shift
key bypassed. You will likely do this dance all day long as you run/test as
user mode, and then flip back in to developer mode (shift key used..so you
don't get the main custom menu). So, you can't develop, or really modify
things when you run your application with the start-up settings...so you
must
shift-by-pass them when you want to work. (or, painfully fully change/edit
the start-up settings. A good set of start-up settings will USUALLY need
to be by-passed for general editing and working on the application)

And, in fact, I use alt-f4 to exit the application...the mdb file should
still be highlighted in the windows explore..so, then you hit enter key
(and, hold down shift key if you need be). This key stroke sequence and
exiting and re-entering the application will occur CONSTANTLY all day long
when you are developing.

When you finally have things just right...you create the mde
you plan to distribute...

You set the shift key on that mde....

The "dance" of going in and out of the appcation is the only real way you
can often test how the appcation will function. In a few cases, you an flip
the form in to view/design mode to test things, but usually with a complex
appcation you have to navigate though a series of forms anyway..so, you got
to start at the "beginning" of the application anyway. So, exit...and
re-enter without using shift key...test...exit...and then re-enter via shift
key to go back to work...

I think it goes without saying that if you adopt the above philosophy of
development, then your users will be running a split database, even in
single user mode, as you can't re-distribute a mde over and over without the
users losing their data. So, splitting is much a prerequisite for using
mde's to update users software.

You can read about splitting here:
http://www.members.shaw.ca/AlbertKallal/Articles/split/index.htm

 

[Guest]

Many thanks Albert.

I'm OK with how to develop the mdb and then convert it to mde before
deployment.

Here are my queries regarding your utility:

1. When I run it, I receive an error saying that certain variables are
undefined. This might be requiring an object definition, since the error
appears even with Option explicit blocked

2. Should the bypass form be set as the Start-up form?

Kind regards:
Anthony Judge.

 

[Granny Spitz via AccessMonster.com]

We have created an Access 2002 Application which refuse to be compiled,
the option is greyed out.

Good. This means that the VBA code is already compiled, not that it's
refusing to compile it. If you don't really mean the "compiled option is
greyed out" but the "Make MDE file" option is disabled, then see the
following.

From
searching through online references we learned that the MDE creation
process can be easily broken

You can only convert an MDB file to an MDE file when certain conditions are
met, like the code compiles, the database format is the same version as the
Access version creating the MDE, etc. If you can't create an MDE then you
need to fix these problems first.

and that a compiled MDE can be decompiled
from tools available from the net.

Hon, those tools available on the internet *don't* decompile an MDE. They
allow you to edit forms and reports in MDE files, but they don't let you view
or change the VBA code or convert the MDE to an MDB.

One company is trying to scare people into paying them $130 for a tool to
"protect" their MDE file from being easily converted to an MDB. The
companies that convert MDEs to MDBs require proof of ownership so if you put
your copyright notice and a way to contact you in the code of your MDE,
you'll find out as soon as someone tries to have it converted. I say *tries*
because these companies won't convert a file for a company named Spacely
Sprockets that says "copyright 2006 David's Databases" and "contact
(e-mail address removed) (800) 555-DAVE." They can tell who the real owner is, so
you don't need to pay a $130 extortion fee.

Without going through the troubles of setting up user level security,
can people help suggest what other simple security provisions are
useful?

Whatever *simple* security you set up without User level security and without
MDEs will be very simple to bypass, like this in the immediate window:

CurrentDb.Properties.Delete "AllowBypassKey"

The next time they open the database, they'll be able to hold down the shift
key and bypass your startup options, code and autoexec macro. Even if you
set up custom menus, hide the database window, etc, it won't matter. The
only way to prevent them from deleting your AllowBypassKey property is to
apply User level security and set the DDL argument when creating the property.
If you have something worth protecting in the application itself, apply User
level security and convert the file to an MDE. If you need to protect the
data, store the data in a client/server database not Access.

 

[Albert D. Kallal]

Here are my queries regarding your utility:

1. When I run it, I receive an error saying that certain variables are
undefined. This might be requiring an object definition, since the error
appears even with Option explicit blocked

Hum, that is strange. Does the application compile? It should run just fine
right out of the box. Perhaps you can try converting it to a2002 format, but
there is NO reason for this.

2. Should the bypass form be set as the Start-up form?

You mean in my sample? Yes, when you run it, the form called frmSetByPass
runs. You are then give the ability to "brose to a mdb, or mde file on your
computer, and then you can set the shift key bypass.

You don't need to import, or include this code/forms in *your* application,
but you can simply use the sample to browse to any mdb (or mde) appcation
that exists on your computer....

So, it not clear about the object definition, but you don't include, or
import the sample into your application. Just run my sample, and use the
"browse" button to browse to a mde file you have on your computer....you can
set/un-set the shift key by-pass...