Protect Your Access MDE's

I was reminded today of the security leaks that exist in MDEs. While the VBA code is stripped, declarations and procedure stubs are retained in the MDE file, and object designs can be hacked.

There are some on the Web, who should know better, selling so-called MDE unlockers and protectors. Ethically, there are two issues here:

1. These apps are marketed as protection aids, but they can also be used by the unscrupulous to do the opposite: get past MDE protection of someone else's database.
   
   
2. How these apps do what they do is not a secret and can be done by anyone with retail Access. If you want to improve the protection of your MDEs or you genuinely need to get into one of your MDE's, before spending any money on these products, read on.
   

On 1 May 2004, I posted on the MDE security issues and protection. The post has been updated and is set out below. Please note that the following does not apply to Access 2007 and ACCDE's, but can be applied to Access 2003 MDB's secured in Access 2003 and then compiled as an MDE in Access 2007. For reasons unknown Microsoft removed Access security from Access 2007.

Did you know that:

1. You can access the Start-Up properties (such as disabling the Shift key bypass) of an MDE through another MDB and change each property.

2. You can open an unsecured MDE with the Shift key, press Ctrl+G to open the Debug window, press F2 to open the Object Browser, and then search all the code modules for procedure stubs, declarations, and constants.

3. You can import all the form and report objects but not the code from an unsecured MDE into an MDB.

Securing An Access Database

To effectively secure an Access MDB you MUST demote the Admin user from the Admins group. Otherwise your database will not be secure, as Admin cannot be removed from the Users group, and anyone using the retail system.mdw file logs on automatically as Admin.

1. Use the Access Workgroup Administrator (AWA), wrkgadm.exe, to create a new workgroup (.mdw) file.

2. Join the new workgroup using the AWA.

3. Make a backup copy of your MDB.

4. Open Access and the database to be secured.

5. Using Tools, Security, User and Group Accounts..., in the User and Group Accounts dialog:

5.1 Create a password for Admin user.

5.2 Create a new user account. This account will be the new database owner account. For example, call the owner account DBOwner. Add "DBOwner" to all groups, including the critical Admins group.

5. Close and re-open Access, logging on as "DbOwner", and leaving the password blank, as you have not assigned one yet.

7. In the User and Group Accounts dialog, demote the Admin user account by removing it from the Admins group. Now Admin is only a member of the Users group and will have only those permissions assigned to that group by "DBOwner".

8. Create a password for "DBOwner".

9. Close and re-open Access, logging on as "DBOwner" using the password you created in step 8.

10. You can now start to secure the objects in you database.

11. In Access 2000 and later, you also need to additonally secure your code by using Password Protection in the VBA Editor.

Special Notes:

• You don't have to distribute your MDW file with your MDE to protect it using this method
  
  
• A User account inherits the permissions of the Group to which it belongs.

Testing:

I have tested an MDE protected with Access security and Password Protection in the VBA Editor with the demos of these two products: Access MDE Unlocker and Access MDE Source Protector, and both products failed to unlock the MDE.

You should test your own MDEs before distribution.

Caveat:

There is no bullet-proof protection against an expert hacker.