Security-Is there a better way?

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

Does anyone know of a better way to secure an Access database than
Microsoft's built-in security system? Although the Microsoft Access Database
Security system works, it is cumbersome. If one is trying to open a secure
database and is not set up for the right ‘mdw’, then all he/she gets is a
message saying that he can’t open the file. If he sets the mdw to the one
for the secure file he may have trouble opening other databases, which have
not been secured.

The problem is that the system is linked to my Access program rather than
the database. Does anyone know of a better system where the security is
linked to the database itself?
 
JR_06062005 said:
Does anyone know of a better way to secure an Access database than
Microsoft's built-in security system? Although the Microsoft Access
Database Security system works, it is cumbersome. If one is trying
to open a secure database and is not set up for the right 'mdw', then
all he/she gets is a message saying that he can't open the file. If
he sets the mdw to the one for the secure file he may have trouble
opening other databases, which have not been secured.

The problem is that the system is linked to my Access program rather
than the database. Does anyone know of a better system where the
security is linked to the database itself?
Click to expand...

No. Security that has any barrier affect at all must by definition be somewhat
cumbersome and complex. If you need better security than the User Level
Security built into Access then you should move to a server based database (SQL
Server, Oracle, etc..)

Instead of making users "join" your secured workgroup give them a shortcut that
specifies your workgroup and file as command line arguments. Then they will get
a login prompt when they open your secured files, but not when they open
unsecured files. The target of such a shortcut would look like...

"path to MSAccess.exe" /wrkgrp "path to MDW" "path to MDB"
 
I'm a little confused by your path. Are you saying I should path users to my
Access program on my hard drive? The database sits on a shared folder on a
server. It's not large enough for SQL or Oracle.
 
JR_06062005 said:
I'm a little confused by your path. Are you saying I should path
users to my Access program on my hard drive? The database sits on a
shared folder on a server. It's not large enough for SQL or Oracle.
Click to expand...

No. The shortcut is to MSAccess.exe on *their* PC. In most corporate
situations that should be identical, but if it's not then you need to create
a shortcut for each user separately. If the location is the same then you
create a single shortcut and copy it to all users PCs.

The "path to MDW" is the path on the network to your shared secured
workgroup file and the "path to MDB" is to the secured MDE/MDB file that
they need to run. If you're doing this right and have split your app then
that second path would be to a local MDE on the users' system. If you have
everyone opening a common MDB file on the network (bad idea) then the second
path would be the path to that file.
 
JR - Rick's advice is excellent and the 'pathed shortcut' to a secure system
is the route to take.

In my example, I have a back-end / front-end set-up and every user has a
copy of the front-end on their PC. They also have a shortcut showing the
path to MSACCESS (runtime in my case) the Front-end and the Workgroup file.
My development shortcut properties looks like this:

"C:\Program Files\Microsoft Access 97\Office\MSACCESS.EXE" "C:\Documents
and Settings\Ian\Desktop\TCIPP Dev\05DevVersionTCIPP.mdb" /wrkgrp
"C:\Documents and Settings\Ian\Desktop\TCIPP Dev\TCIPPWKGRP2.mdw"

The runtime is a switch (/runtime) added to this string on my production
shortcut.

"C:\Program Files\Microsoft Office\Access97\Office\MSACCESS.EXE" /runtime
"C:\TCIPP\AAA_New_TCIPP_Dev_Files\05DevVersionTCIPP.mdb" /wrkgrp
"C:\TCIPP\TCIPPWKGRP2.mdw"

I use WISE installer and that creates the shortcut for me whilst installing
the runtime and front-end on a users PC.

I also use SageKey scripts to install a runtime that does not interfere with
current access installations or removals etc.

The Workgroup file is usually on the network server where the back-end is
located too.
 
There are many alternatives to using Access Security when it comes to
securing your database.

Making regular backups, hiding your tables, distributing a .mde file,
and/or using the /runtime switch to open the application can help keep
a malicious or curious user from doing much damage.

For a comprehensive look at this issue, Garry Robinson has written a
great book entitled "Real World Microsoft Access Database Protection
and Security". More info is here:
http://vb123.com/map/

A shareware version of a simplified user security add-in - LASsie
(Light Application Security) for MS Access - is available for download
here:
http://www.peterssoftware.com/las.htm

Also, there's the Access Project Security Manager from
databasecreations, Inc.:
http://www.databasecreations.com/prod_apsm.htm

Hope this helps,

Peter De Baets
Peter's Software - Microsoft Access Tools for Developers
http://www.peterssoftware.com
 
I have to take issue here and I'm happy to be corrected if I'm wrong but ...
There are many alternatives to using Access Security when it comes to
securing your database.
Click to expand...

That rather depends upon how you define "security".
A shareware version of a simplified user security add-in - LASsie
(Light Application Security) for MS Access - is available for download
here:
http://www.peterssoftware.com/las.htm
Click to expand...


The link states "LASsie is called "light" application security because it is
not intended to be a robust, high-end security application. In fact, a
sophisticated user could edit the underlying tables and change their own
security level."

Access ULS is also not intended to be a "robust, high-end security
application"; a "sophisticated user" can defeat ULS with the right tools.
 
Keith Wilby said:
Access ULS is also not intended to be a "robust, high-end security
application"; a "sophisticated user" can defeat ULS with the right tools.
Click to expand...

My previous message went incomplete, finger trouble.

My question is, why would anyone pay money for an app that is even less
secure than the built-in security? So it's easy to set up. OK, well so is
ULS once you've mastered it. In my experience, there's always a "dabbler"
in most organisations that would relish the chance to break a home-grown
security setup, so where's the value?

Keith.
www.keithwilby.com
 
Keith said:
My previous message went incomplete, finger trouble.

My question is, why would anyone pay money for an app that is even
less secure than the built-in security? So it's easy to set up. OK,
well so is ULS once you've mastered it. In my experience, there's
always a "dabbler" in most organisations that would relish the chance
to break a home-grown security setup, so where's the value?
Click to expand...

To me this has a large "HR management" aspect to it. A snoopy "dabbler" can
break into most any home-grown Access security and could still declare innocence
if discovered. "Hey I was just trying to import some tables into my own file.
I didn't even realize that everyone else's passwords would be in there."

While the built in security is hackable anyone caught doing so would not be able
to pawn it off as an accident. The clear and explicit steps required to break
ULS would make it very apparent that gaining access to forbidden data was in
fact exactly what the person had in mind.

Having said that I would still never put anything sensitive in an MDB file that
needed to be shielded from users of the same file if I had better alternatives.
 
It's no great suprise that the spammer hasn't returned to defend his
product.
Click to expand...

I wouldn't call Peter a spammer. In fact he's been rather helpful. I use his
Label Saver in a couple of applications I've built.
 
This "system" is like locking the front door of a house and hoping no
one notices the back door is wide open: there's a degree of access
control, but absolutely no security.

Even the author admits as much, saying "...and my 12 users do not know
it can be circumvented".
 
Back
Top