Hi Lynn,
There are three possible weaknesses with vPPC (when used with an
Access back end) that I know of. These are:
1) Ability to get at the data via Automation if the hacker knows the
location of the back end. An example of this might be where a form is
open in the Access front end and a user uses VBA from another
application, e.g. Excel. If they use GetObject to hook into the
already open Access application, they can use this to
read/modify/delete data in the back end if they know where that back
end is. If they know or can guess the names of the tables in the back
end, they can do this quickly; if they don't, they could find out the
names from one of the system tables. However, if the back end location
is not known to the hacker, I don't know of any way of getting at the
data using "normal" methods such as using VB/VBA. Note that if the
back end is a server database such as SQL Server, it appears to be
free from this weakness.
Having said all the above, I can't remember how I hacked into a back
end. It is a while since I did it and didn't keep my code. Will try
again later. I wonder whether I had got some linked tables in my front
end at the time and was looking at those....
2) "Mining" the mid-tier database password from the front end. In my
example, I just set up that password in the declarations section of a
module. It may be that if the front end is encrypted that this will
stop people from getting to it from some tool outside Access. If the
encryption method is all it is cracked up to be (pun intended) and you
make the front end into a .accde file, maybe this is sufficient. If
not, obfuscating it may be the only means of hiding it, e.g. creating
on the fly with some really obscurely written code.
3) One of these sniffer thingies that can read network traffic and
which can pick out the database password as it whizzes across the
network. If there is a possibility of this happening, then we are in
trouble (as are SQL Server junkies using SQL Server authentication?).
Alan