Securing a DB

[Anubis3000]

Hi,

My question is in regards to securing access databases.

Thus far, I have converted my front end into an .mde file, removed all of the menus and disabled the shift key at startup (normally, if you hold down the shift key at startup, it halts the exection of vb and displays the default menu). My question is, is the database now hackproof? Are they any other "special" keys (like shift at startup) I should be aware of? thnx.

 

[PHV]

With linked tables in another .mdb anybody may change the data ...

Hope This Helps, PH.
Want to get great answers to your Tek-Tips questions? Have a look at FAQ219-2884 or FAQ181-2886

 

[easyit]

Google for "office password recovery". Nice tools available that will hack your DB (or other Msoffice passwords).

However, these tools need access to the mdw file. If you can hide the location your much safer. This however probably needs additional programming in VB. I have no experience with it but have read somewhere that it can be done (maybe on tek-tips, not sure). Other solutions could be of course to use a different back-end, sqlserver, oracle, mysql etc. Your MDE file is secure, I have not heard of anybody doing reverse engineering on it. The shift key is easily enabled again by a programmer or advanced DB user.

Al this leads to the obvious question : what kind of security do I need? Just to prevent users from messing around, or true data security, ie prevent unauthorised access?

EasyIT

 

[Anubis3000]

Thank you all for your replies.

To give you some more information, my front end is secured using a series of user/password forms that are set to open at startup (these are forms that I created myself). Additionally, my backend is secured using a password (Tools ->Security->Set Database Password). Also, the initial form that opens at db startup automatically disables all toolbars, and shift has been disabled. Also, all windows that would normally startup (Tools->Startup) have been disabled. Any additional thoughts? thnx again.

 

[easyit]

Hm,

I think there are some drawbacks on these setup - in db& user management, but if it works for you...
On the security side, you may have a nice advantage, and that is that the you don't have a shared workgroup file that is hack-able because the link to it is stored in a FE mde. If however your backend location is known to others, then the advantage is gone.

If your mde file is OK, than the only worry is the backend. I don't know about the do's and don’ts on DB password protection. I think it is not so wise because every user logs into it as an administrator which can give you stability problems. Maybe somebody else out here has more experience with it?

EasyIT

 

[GingerR]

Like PHV says: unless you use Access Security, any user can make a new blank db, copy your front-end links to it, and open the back-end tables. try it out.

Want to get great answers to your Tek-Tips questions? Have a look at FAQ219-2884 or FAQ222-2244. Basics at

http://r937.com/relational.html

 

[easyit]

GingerR,

how do you get the links if they are in the compiled mde?

 

[GingerR]

FILE+GET EXTERNAL DATA+IMPORT

Want to get great answers to your Tek-Tips questions? Have a look at FAQ219-2884 or FAQ222-2244. Basics at

http://r937.com/relational.html

 

[Anubis3000]

Is there any way to prevent users from creating table links to my front end?

I thought that my front end would inherit (i.e. users would have to enter back end password to link to back end table) the security of the back end, but apparently not......

thnx again

 

[GingerR]

Use Access Security

Want to get great answers to your Tek-Tips questions? Have a look at FAQ219-2884 or FAQ222-2244. Basics at

http://r937.com/relational.html

 

[Anubis3000]

Sorry, I ment to ask if there is anyway to prevent users to link to my front end without using access security. If I were to do that then I would have 3 files to open a single front end and that might be too complicated for my users....

One method I have found is to put the prefix "Msys" in front of my tables I want to hide, and making them hidden in my front end. When users attempt to link to them, they do not see them. However, this can be easily defeated by viewing hidden and system tables (tools->options).

Another way I was thinking was to set a database password (tools->security->set database password) for my front end, and then somehow using command line options (tools->options) to automatically open the front end with the forementioned password. This way, to the user, the front end would not seem to have a pwd, however if linked, they would be prompted for one. However, access does not save my command line options, so i am not sure about this.

thnx again.

 

[psemianonymous]

What everyone's trying to tell you is that you can never prevent someone from opening your Access database from within Access. It's all crackable.

Instead, use other laysers of security:

1. The filesystem - put the database on a network share folder, restrict access to this folder to ONLY the people who use the database. This works.

2. Move the tables to a server-based db (like SQL Server or Oracle or whatnot) and tie the security either to their Windows logon or their database logon.

Your third option is:

3. Give up trying to totally secure your Access database, as it's pretty much impossible.

 

[GingerR]

Not sure what you mean by

If I were to do that then I would have 3 files to open a single front end and that might be too complicated for my users

Why not just use Access Security? I was afraid and avoided it for years, using all kinds of tricks and such as you are trying to do. Once a friend showed me how to set it up, and now it is so easy. The user just has a shortcut on their desktop to open the db, just like any other db. I just make all users (user = 'admin') one GROUP ("Users") and the User "SysAdmin" (me) in another group ("Admins"). Anyhow, that's standard set up. Every new db I make, i just set it up so simply using the same .mdw file. No issues. Try it out.

Want to get great answers to your Tek-Tips questions? Have a look at FAQ219-2884 or FAQ222-2244. Basics at

http://r937.com/relational.html

 

[Dor100]

In addition to Shift, you also have to disable F11,but it's almost a moot point anyway.

One big disappointment to me is that I thought all the great wisdom about creating RWOP queries and then removing permissions on tables themselves would solve the problem of unwanted table-linking capability, but for some unknown reason I have found so far the RWOP queries simply do not work. I'm running Acc XP on a Novell client for Windows (2000).

If you can get RWOP queries to work the way they're supposed to, then you can also use some code to check if a user has the DB window open and then shut down the whole database if he/she does. The code would run in the On Timer event of various forms, and you would have other code in place so that there can never be a situation in which at least one of the forms is not open.