Dan Waters
dwaters at usinternet.com
Sun Nov 16 17:16:24 CST 2003
Michael, I tested a situation once where I was able to put the .mdw file (not system.mdw) into a separate folder on a server, where this folder had network security applied so that the only people who could open the folder directly were network administrators. Each user had a shortcut on their desktop which listed the full paths to the Access file, the .mdb file, and the .mdw file. The user was able to open the database, security worked correctly, but they couldn't get at the .mdw file. I never found any documentation for this, and I've only tested this setup at one location so far. I'll try it again next chance I get. Dan Waters Quality Process Solutions -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Michael Brösdorf Sent: Sunday, November 16, 2003 4:37 PM To: Access Developers discussion and problem solving Subject: AW: [AccessD] POLL: Access Security Hi, I didn't read the whole thread, so please forgive me if I repeat things. It is not too complicated to apply user security to both FE and BE (plus, you can always lock up the FE by converting it into an MDE). The main problem with Access security is the mdw. There is a couple of programs out there that can simply read all user names and passwords from an MDW file. AFAIK there is no way to avoid that. So, with an Access BE the only option would be to ship an MDW that does not contain a user account that allows access to sensitive information. But that doesn't make sense anyway if someone is supposed to actually work with the db ;-) Maybe encrypting data with a user defined function in the MDE(!) is an option. The BE would than contain only encrypted data. Anyone with the right tools could read the data, but that would be useles unless they know how to do crypt-analysis - just a thought... HTH, Michael -----Ursprüngliche Nachricht----- Von: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com]Im Auftrag von Drew Wutka Gesendet: Freitag, 14. November 2003 19:08 An: 'Access Developers discussion and problem solving' Betreff: RE: [AccessD] POLL: Access Security I think you're agreeing with me. <grin> The problem with a BE though, is that if it's an .mdb, it has to be accessible by the user, in order for an Access (or even VB) FE to use it. You're right, if you go with a server side db, like Oracle or SQL, then you have that security in place, but even that stuff isn't unbreakable. The ASP FE let's you use an .mdb as a backend, but since it doesn't need to be accessible by the user, it is pretty 'tight' security. Drew -----Original Message----- From: Jim Lawrence (AccessD) [mailto:accessd at shaw.ca] Sent: Thursday, November 13, 2003 10:05 PM To: Access Developers discussion and problem solving Subject: RE: [AccessD] POLL: Access Security Drew: That is the whole issue surround Access security, is that a fully exposed MDB is very hackable. If the DB can be hidden behind a ASP FE or simply replaced with another remote BE, some other SQL, the whole security issue is non-starter and hardly has to be addresses at all. In my humble opinion. Jim -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com]On Behalf Of Drew Wutka Sent: Thursday, November 13, 2003 10:56 AM To: 'Access Developers discussion and problem solving' Subject: RE: [AccessD] POLL: Access Security Actually, an .mdb can be made VERY secure by using ASP as a front end. The problem with using Access or even VB for a front end, is that you need to have direct access to the back end. So if user XYZ is logged on, XYZ needs permission to have direct Access to the .mdb AND the .mdw. However, if you use ASP as the Front End, so the user is using their browser to access the db, then the users can be completely stripped of access to the .mdb itself. In fact, if you store the .mdb on the IIS server, and you don't even have to have share access to it. Sure, you're then relying on NT security, but you can button that down pretty tight. So you can keep the .mdb and the .mdw at an 'unavailable' location. I've used Access User Level security quite a bit, I don't find it difficult at all (partly due to so many similarities between it and NT security). However, it is a pretty fallible system. With enough time and resources, and it can be cracked. Actually for $40 (last time I checked), you can crack any .mdb, as long as you have a copy of the .mdw with the administrative accounts in it. Even with a solid knowledge of Access User Level security, you are still dependant upon the users ignorance for it to be secure. With what I was talking about with an ASP front end, you are taking the level of security to a point where a SERIOUS hacker would be required to get at whatever you want protected. Drew -----Original Message----- From: Rocky Smolin - Beach Access Software [mailto:bchacc at san.rr.com] Sent: Thursday, November 13, 2003 9:03 AM To: Access Developers discussion and problem solving Subject: Re: [AccessD] POLL: Access Security But seriously there are some apps, like the HR apps (someone, I forget who, wrote in about) where you want it real secure. But even in that case, passwording the back end and maybe encrypting it, with some additional restrictions in the front end like I use and then making an mde would seem to do the trick without having to get mixed up in all that mdw stuff. Rocky ----- Original Message ----- From: "Rocky Smolin - Beach Access Software" <bchacc at san.rr.com> To: "Access Developers discussion and problem solving" <accessd at databaseadvisors.com> Sent: Thursday, November 13, 2003 6:40 AM Subject: Re: [AccessD] POLL: Access Security > Hahahahahahahahahah....sorry. > > Rocky > > ----- Original Message ----- > From: "Gustav Brock" <gustav at cactus.dk> > To: "Access Developers discussion and problem solving" > <accessd at databaseadvisors.com> > Sent: Thursday, November 13, 2003 5:55 AM > Subject: Re: [AccessD] POLL: Access Security > > > > Hi Rocky > > > > So why is JC's world so much different from yours and mine?? > > > > /gustav > > > > > > > Had to fool with it once on a legacy app and got around it. But > > > it was > a > > > big PITA. > > > > > I generally roll my own by having the user log in with a password. They > get > > > one of three levels of access to the whole system - 1) read only, > > > 2) read/write, 3) admin. I put their access level in a global > > > variable. > Each > > > form has to check the access level then to see if they are allowed > > > to do > a > > > certain function. So far, the three levels have been adequate and > > > no > one > > > except for one client has wanted function of field level control. > > > > _______________________________________________ > > 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 > _______________________________________________ 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 _______________________________________________ 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 _______________________________________________ AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com