Question about database security

[theDBguy]

The whole thing is out the window if they have disabled macros or copied the database to un-trusted location, in which case the 'Autoexec' (verify user function) is not performed. Now they have access to everything.

Hi. As I said earlier, since you're using a file-based security, you cannot prevent anyone from stealing the file and breaking your security. However, I would say the above quoted statement is not entirely true. If you put an Access database in a non-Trusted Location, VBA is disabled, but macros are not. So, when you say "they have disabled macros," I would like to know how exactly "they" are doing this. In any case, I told you what you could do to avoid giving away what you don't want them to steal, which was, don't include anything in the file unless the code can run. In other words, if the user improperly opens your db, it's empty. Otherwise, it's full of stuff. Also, telling us exactly what you're trying to protect would help in giving you more specific advise. For example, if you're trying to protect your VBA code from being modified or copied, then you can convert/compile your application into a ACCDE.

 

[isladogs]

So why don’t you do exactly what I suggested in post #6 which covered all the points you have described.

 

[sumdumgai]

From what I'm seeing, if the macro is a 'run code' macro, and if either 'macros are disabled' in the Trust Center Settings, or if 'macros are disabled' and the database is not in a trusted location, then the macro errors with '2001'.


I have VBA code locked from viewing with a password.

 

[theDBguy]

From what I'm seeing, if the macro is a 'run code' macro, and if either 'macros are disabled' in the Trust Center Settings, or if 'macros are disabled' and the database is not in a trusted location, then the macro errors with '2001'.

I have VBA code locked from viewing with a password.

Hi. You're correct. When VBA is disabled, then macro calls to VBA will error out. So, what I was saying was test first if you can call VBA from your macro. If not, then get out; otherwise, continue on. I already told you how to test if VBA is disabled or not from a macro.

PS. I almost missed it... You just told us how you disable macros - through the Trust Center Settings. Unfortunately, I just gave it a try and selected "Disable all macros without notification," but my Autoexec macro still fired even when the file was in a non-trusted folder. So, I think what I was saying, to put a test for VBA availability from the Autoexec macro, should work and help you overcome some of your concerns. However, if the user uses the shift bypass, then all bets are off. This is a limitation of Access, and we all have to live with it. The only way around it is to only run your application in Runtime environments.

 

[sumdumgai]

Thanks isladogs. Your suggestion in Post 6 is now what I'm trying to do.

 

[sumdumgai]

theDBguy. I need help with that. What would the macro look like? I tried to do some error handling but got hung up with a named error handler macro not being in the Autoexec group. Thanks.

 

[theDBguy]

theDBguy. I need help with that. What would the macro look like? I tried to do some error handling but got hung up with a named error handler macro not being in the Autoexec group. Thanks.

Hi. I gave it to you in Post #7. You can use an If/Then action to test for [CurrentProject].[IsTrusted].

One thing I will say about the option between using an Autoexec macro or a Startup Form is this: An Autoexec macro will fire - no mater what; whereas, a Startup Form will always open, but may not run any code at all, if code is disabled.

 

[sumdumgai]

So, does 'IsTrusted' mean that 'Macros are enabled'; i.e., that a 'run code' macro will run? If 'macros are disabled' but the database is in a trusted location, does that also mean that the macro will run?


Thanks.

 

[sumdumgai]

So I moved the verify user code to a load event for a hidden form. After a lot of testing and adjusting everything seems to work the way I want except for one kludge. For an 'Admin' person wanting to open the FE, ribbon menus and shortcuts are initially disabled. That's because the unload event for hidden form sets those properties to off. So, for an Admin person, I set those props to on and then issue a message directing the Admin person to shut down the database and restart. I know this is off subject of this post so if anybody has any ideas I can start another post.

 

[theDBguy]

So, does 'IsTrusted' mean that 'Macros are enabled'; i.e., that a 'run code' macro will run? If 'macros are disabled' but the database is in a trusted location, does that also mean that the macro will run?

Thanks.

You can say that, but I would say "IsTrusted" means the file is well, "trusted" either as a document or stored in a trusted folder. If so, code is enabled.

 

[sonic8]

Don't use an autoexec macro.
Move the code from the autoexec macro to the load event of a start-up form.

How is a startup form any better than an AutoExec macro?

 

[sumdumgai]

When I first posted this topic, I had encountered what I thought was a hole in security when I used Autoexec (RunCode) to verify user-id and password. The hole occurs when the user has not enabled macros or when they move the database to an un-trusted location. In either of those cases, the Autoexec macro errors and then leaves the database in an exposed state. Moving that verify code to a form event eliminates that hole as does putting a check in Autoexec for [CurrentProject].[IsTrusted]. A user could also bypass Autoexec macro with Shift Key Bypass.

 

[The_Doc_Man]

Ah, but there is a way to disable that Shift Key bypass as well.

Search this forum for "Securing a database" and I'm sure you will find the articles on how to do that.

 

[Deleted member 147267]

You said shift bypass was disabled in 1st post?

Upon opening the frontend (shift bypass is disabled)...