Rocky Smolin
rockysmolin at bchacc.com
Mon Apr 26 15:00:38 CDT 2010
Mark: 1) yes 2) any access mdb Rocky -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Mark A Matte Sent: Monday, April 26, 2010 12:00 PM To: accessd at databaseadvisors.com Subject: Re: [AccessD] Database Needs Password Protection 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:W L:en-US:WM_HMP:042010_1 -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com