[AccessD] Database Needs Password Protection

Mark A Matte markamatte at hotmail.com
Mon Apr 26 14:00:13 CDT 2010


Rocky,

 

Can I ask in a slightly different way???

 

1.  Are you trying to keep people from opening the backend directly?

2.  Can the user link to the BE from any access MDB or just your app?

 

Thanks,

 

Mark A. Matte
 
> From: rockysmolin at bchacc.com
> To: accessd at databaseadvisors.com
> Date: Mon, 26 Apr 2010 10:18:00 -0700
> Subject: Re: [AccessD] Database Needs Password Protection
> 
> 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
> 
> -- 
> AccessD mailing list
> AccessD at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com
 		 	   		  
_________________________________________________________________
Hotmail has tools for the New Busy. Search, chat and e-mail from your inbox.
http://www.windowslive.com/campaign/thenewbusy?ocid=PID28326::T:WLMTAGL:ON:WL:en-US:WM_HMP:042010_1


More information about the AccessD mailing list