Prevent Linking to Access Tables with (or without) the Security of a Workgroup

[robboll]

Even if you secure your MS Access database using proper procedure, a
user can create a new access database and use his password to link to
the backend data. This will allow him to bypass any restrictions to
the data that your client might have. I've looked through years of
posts concerning this very issue and so far the best solution I've
found is to put the back-end in a hidden directory.

There are ways of preventing shift-bypass to open the database. What
about an option to only allow one link to the data -- your client MDB
or MDE file? That would be a really nice feature! Any hackers got an
approach to this? How to prevent linking to an MS Access database
with or without MS Access security.

If your reply is something to the effect that it can't be done.
PLEASE don't reply. This question has been repeated over several
years. There needs to be a solution.

RBolling

 

[Scott McDaniel]

Even if you secure your MS Access database using proper procedure, a
user can create a new access database and use his password to link to
the backend data. This will allow him to bypass any restrictions to
the data that your client might have. I've looked through years of
posts concerning this very issue and so far the best solution I've
found is to put the back-end in a hidden directory.

A hidden directory works well, as does changing the name of the file extension. Neither, however, will stop anyone from
linking to or importing from the database.

If you build the database using RWOP queries, then remove all permissions from the tables, uses can't link to or import
the tables, even with a valid username/password. In other words, create a RWOP query for every table, and use that query
instead of tables. There are some caveats to using RWOP queries; see Joan Wilds site for more info:
http://www.jmwild.com/RWOP.htm

There are ways of preventing shift-bypass to open the database. What
about an option to only allow one link to the data -- your client MDB
or MDE file? That would be a really nice feature! Any hackers got an
approach to this? How to prevent linking to an MS Access database
with or without MS Access security.

Jet is not a client server database, and doesn't care who connects to or uses it, assuming that no security has been
applied. A client server type database will authenticate each user or connection, and can then allow or deny those
connection, or provide particular users with subsets of tables, etc as needed. Jet has no such ability; it's a file
server database, which means it's nothing more than a file, much like a text document. You can implement Windows
security on the file and folder, but users require a certain level of pemissions on both in order to be able to use a
Jet database. If you want a particular group of users to have only Read permissions on the file, then you can setup
Windows security to allow those users only Read permissions on the database (those users would still need
read/write/create/destroy permissions on the folder in order to create or manipulate the lockfile, however). Of course,
those users would then NOT be able to update any data, regardless of whether they did so through your interface or
directly through Access ...

Even with security applied, a user with a valid username and password can still access the data, as you've mentioned.
The only solution to that is moving to a more secure platform.

If your reply is something to the effect that it can't be done.
PLEASE don't reply. This question has been repeated over several
years. There needs to be a solution.

This has been beaten to death, as you've seen from looking through "years of posts" without finding any solutions. The
reason is simple: it can't be done. I realize you specifically stated that you didn't want that answer but sometimes the
truth isn't what we want to hear.

RBolling

Scott McDaniel
scott@takemeout_infotrakker.com
www.infotrakker.com

 

[robboll]

A hidden directory works well, as does changing the name of the file extension. Neither, however, will stop anyone from
linking to or importing from the database.

If you build the database using RWOP queries, then remove all permissions from the tables, uses can't link to or import
the tables, even with a valid username/password. In other words, create a RWOP query for every table, and use that query
instead of tables. There are some caveats to using RWOP queries; see Joan Wilds site for more info:http://www.jmwild.com/RWOP.htm




Jet is not a client server database, and doesn't care who connects to or uses it, assuming that no security has been
applied. A client server type database will authenticate each user or connection, and can then allow or deny those
connection, or provide particular users with subsets of tables, etc as needed. Jet has no such ability; it's a file
server database, which means it's nothing more than a file, much like a text document. You can implement Windows
security on the file and folder, but users require a certain level of pemissions on both in order to be able to use a
Jet database. If you want a particular group of users to have only Read permissions on the file, then you can setup
Windows security to allow those users only Read permissions on the database (those users would still need
read/write/create/destroy permissions on the folder in order to create or manipulate the lockfile, however). Of course,
those users would then NOT be able to update any data, regardless of whether they did so through your interface or
directly through Access ...

Even with security applied, a user with a valid username and password can still access the data, as you've mentioned.
The only solution to that is moving to a more secure platform.




This has been beaten to death, as you've seen from looking through "years of posts" without finding any solutions. The
reason is simple: it can't be done. I realize you specifically stated that you didn't want that answer but sometimes the
truth isn't what we want to hear.




Scott McDaniel
scott@takemeout_infotrakker.comwww.infotrakker.com

I'll have to go with the hidden directories and (as you suggest)
rename the file suffix. I am already using RWOP queries. Your
"truth" is a little easier to swallow and I appreciate your
suggestions. Thank you.