CODEWITHSUNDEEP
ms-accessvbams-access-2010
Leroy
Leroy

Reputation: 644

Prevent enabling of shift bypass - Access 2010

I am trying to prevent database users from being able to view the linked tables in the navigation pane of an Access 2010 database. I have hidden the pane and disabled the F11 key.

I am aware that you can disable the functionality of the SHIFT key that permits you to bypass the access start-up options as per this article.

My question is whether it is possible to prevent a user from re-enabling the shift key either from within the database itself or remotely via another database. If this is not possible does anyone know of the next best method I can use to prevent users viewing the tables in the navigation pane (I know access isn't the most secure database but it's all we have in the office atm)

Thanks

Upvotes: 1

Views: 2616

Answers (2)

Erik A
Erik A

Reputation: 32642

My approach to security in Access is the following:

Encrypt the main database using a complex password.

Use a second database to log in to this encrypted database. The second database stores usernames, user salts, and an encrypted version of the main database password with the user password. This way, no user needs to have the main password.

Then, compile the second database, so it's harder to modify the database and print the main encryption key.

Weaknesses:

  1. Revoking access to a certain user only works if he doesn't have a backup of the login database (or you have to change the encryption key on the main database, forcing you to recreate accounts for every user).
  2. The encryption I'm using is RC4 (implementation in VB by wqw found as an answer here), which isn't that strong
  3. A tech savvy user that has a valid password could decompile the database and use it to acquire the main database password
  4. If you're not signing your databases and enforcing all databases to be signed, someone might modify or replace it to weaken security

To go through all the details is too much, so here is my implementation.

File metadata: size: 672 KB, SHA1 hash: 19A6C756B8D5B0CDCEBE505B289062A1BBD94DEC

Quick manual: on first run it prompts main database password, location, first user name and password. After that, you can just use the forms to do anything you want.

Note that it's earlier work, and I haven't deeply thought about SQL injection (I use doublequote escaping and am ashamed for it). However, this isn't a security risk for the main database, it only opens up a possibility for a destructive hack (and someone with write access to the database file can probably destroy it anyway).

It's not compiled and menus aren't hidden, so you can easily inspect and modify it. When implementing it, hide all menus and compile it.

The database, as all SO content, is licensed CC BY SA 3.0

Upvotes: 5

Albert D. Kallal
Albert D. Kallal

Reputation: 49039

Of course using SQL server for the back end will not change this issue. (so suggesting's to use SQL server will NOT fix this issue). If users can grab + see the data from SQL server, then in Excel, or via linked tables in Access would not change this security issue. What you can do however is in your Access startup code check if shift by-pass has been enabled and then disable it, and then exit the database. (it requires a re-start to take effect). So even if users disabled the shift key, your startup would re-enable. And using a compiled (accde) will prevent users modifying any code.

So simply check the status of the shift key on application startup, and if its been enabled, simply use your referenced code to disable the shift key and exit.

To be fair, the above is not 100% solid, since in theory your startup code would not run if the shift key was enabled. Another tip would be to always provide users with a shortcut to use (and that shortcut would include the /runtime switch which also disables shift key regardless of setting - so this would give "somewhat" an extra layer here.

Upvotes: 0

Related Questions