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