[AccessD] Database Needs Password Protection

First of all Rocky, you must understand that there is currently NO way
to secure an Access mdb (2003 or earlier) that a person with power user
or better skills couldn't overcome, IN AN ACCESS FE/BE SCENARIO.  I
believe 2007's password system is harder to crack, but it'll eventually
be cracked too.  (Everyone thought WPA2 security was uncrackable, it's
not anymore...).  When it comes to security, one must always realize
that no system is 100% secured.

With that in mind, if you are keeping with an Access FE/BE scenario, you
must decide what level and how you want to implement security.
Obviously breaking from the Access FE/BE model would make your security
much more difficult to break.  But let's stick with your model.

First, as it's already been mentioned, database passwords have cracking
utilities out there that anyone with Google access can find and use.
Plus, a database password is just a door (with a publicly obtainable
lock picking kit), it does nothing about read/write.

Second, NT security is just a bigger more secure door.  So if you want
to give user A access to read/write a database that his normal NT
account only has read permissions for, they would have to log in with a
new account (on their computer), or you have to jump through hoops
having them open the db with 'run as'.

Access User Level security has flaws, but it the best tool to lock down
an Access FE/BE system.  It's not available in a 2007 format database.

Here's how Access User Level security works:

User names, group names, passwords and user group membership, are stored
in an .mdw file.  This file IS crackable.  Just like access database
passwords.  (However, if you keep reading, there is a way to guard
against that....).  For the purposes of making this a little easier to
understand, I'm going to ignore groups.  There are no real special
features of a group.  Groups just allow you to give multiple users the
same permissions more easily.

Permissions for Users and Groups are stored in the .mdb.

The way an .mdw file works, is that when a user is created, you are
prompted for their name and user ID (UID).  The only time you get
prompted for the UID is during user creation.  The combination of the
USER NAME and the UID is what is used in the creation of the 'hash' that
the .mdw hands off to JET, to be used in the .mdb.  The password is
irrelevant.  It is only used in the normal usage of an .mdw.  Every .mdw
has an 'Admin' account, (which also will always have the same UID).  So
when you open a standard .mdb with Access, Access tries it's 'default'
.mdw with Admin as the username, and a blank password, if the .mdw has a
blank password for the Admin account, it returns a 'hash' representing
the Admin account to Access, which it then uses with JET to interact
with the .mdb it is opening.  If there is a password on the Admin
account in the .mdw, it then prompts the user for a User Name and
password, and if a correct combination is entered, that 'hash' is then
sent to JET to open the .mdb.

So to sum up so far, the .mdw just gives Access a 'hash', which is the
combination of the User Name and UID, to use in an .mdb.

The .mdb then has permissions, for EVERYTHING (read/insert/update/delete
for data, design read/write, etc, for every object type in the .mdb,
including the database itself).  These permissions go off the hash
(though the interface shows you user names(and groups) from the current
.mdw).  This is where the fatal flaw in Access User Level security is.
Someone that knows DAO pretty well can actually spoof the 'hash',
without an .mdw at all.  Don't ask me how, I'm really not that great at
DAO, but I know you can do it.  However, as I said, if you can ignore
this one flaw (which you have too, if you want to 'secure' an .mdb with
sticking to an Access FE/BE scenario), then you just have to follow some
simple rules to secure a database with an .mdw.

First, don't give the Admin account ANY permissions that you don't want
EVERYONE to have.  Because it doesn't matter if you put a password in
YOUR .mdw, simply creating a new .mdw allows any user to have the same
credentials without a password (because the 'hash' provided by a new
blank .mdw will be the same as any .mdw you put a password on the Admin
account).

Next, the cracking tools that 'hack' .mdw's must have access to the
.mdw.  So if you limit who has the .mdw's with higher level access, you
limit who can actually do admin level tasks (with the exception of the
DAO loophole).

Record the Usernames and UID's that you use to create an account,
because a lost or corrupted .mdw account can only be recreated with that
information.

Other than that, Access User Level security can allow you to control
every aspect of 'security' within an .mdw, in regards to any Access
object.

Drew

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Rocky Smolin
Sent: Monday, April 26, 2010 8:25 AM
To: 'Access Developers discussion and problem solving'
Subject: Re: [AccessD] Database Needs Password Protection

Lambert:

His requirement is that anyone who tries to modify the back end directly
will be unable to do so but will still be able to modify the data
through
the front end. It looks like with your approach a member of the group
will
be able to open the back end directly and be able to modify the data in
the
tables.  True?

Rocky
 
The information contained in this transmission is intended only for the person or entity 
to which it is addressed and may contain II-VI Proprietary and/or II-VI Business 
Sensitive material. If you are not the intended recipient, please contact the sender 
immediately and destroy the material in its entirety, whether electronic or hard copy. 
You are notified that any review, retransmission, copying, disclosure, dissemination, 
or other use of, or taking of any action in reliance upon this information by persons 
or entities other than the intended recipient is prohibited.