[AccessD] Database Needs Password Protection

Rocky Smolin rockysmolin at bchacc.com
Mon Apr 26 12:18:00 CDT 2010


Drew:

Thanks for the info.  I'm really resisting going the mdw route because so
far, over the last x years, this user is the only one who has asked for
stronger password access than is already built in to the application.  

In order to avoid having to support multiple Fes with mods from different
customers, I hide the custom mods and trigger their visibility based on the
serial number of the user to whom the FE is licensed.  This works well. 

So I'd like not to put anything into this application that makes it harder
for everyone else.

Rocky


-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Drew Wutka
Sent: Monday, April 26, 2010 9:53 AM
To: Access Developers discussion and problem solving
Subject: Re: [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.


--
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com




More information about the AccessD mailing list