First Published 12 Mar 2022                     Last Updated 30 Apr 2023                     Difficulty Level : Moderate

Section Links:
        Suggested Improvements
        Summary
        Feedback


The first two parts of this article explored ways of improving the security of Access databases with existing security features.

This page discusses my wish list for additional features that would have a significant impact on Access security together with reasons for each of these items.

Before going any further, I should again stress that:
1.   no Access database can ever be made 100% secure against deliberate attacks by skilled and determined hackers with sufficient time and motivation.
2.   If your data is very sensitive, it should be securely stored in SQL Server (or similar BE database)

Nevertheless, there any many reasons why improving Access security would be beneficial.
For example, improvements to prevent accidental or deliberate tampering by authorised users.

In my opinion, it should be possible to make ACCDE files more secure without affecting functionality in ACCDB development.

To that end, and based on numerous questions in various forums as well as my own experience, I would like to see the following changes to compiled ACCDE files ONLY:



1.   Suggested Improvements                                                                                       Return To Top

a)   mask password strings in the MSysObjects system table

      Currently all passwords are clearly displayed in MSysObjects.
      These should be masked using ******** as is the case elsewhere in e.g. input masks



b)   prevent tables and queries being exported to another database

      ACCDE / MDE files prevent forms, reports and modules being exported to protect your database design.


      However, ACCDE / MDE files do NOT prevent moving / editing / deleting tables or queries. Data is not protected

c)   prevent table/query design being modified

      Similarly, ACCDE / MDE files prevent changes to the design of forms, reports and modules
      However, there is no restriction on table/query design changes in ACCDE/MDE files

d)   block all access to hidden & system tables

      System tables provide a lot of information that is useful for developers, there should be no reason for end users to access system tables.
      Any required functionality should be built into forms. However, system tables remain accessible even in ACCDE/MDE files


e)   don't show a list of procedures, constants (and their values) in the Visual Basic Editor (VBE)

      One of the main reasons for distributing databases as ACCDE / MDE files is that the VBA code cannot be viewed or edited.


      However, it is very easy to get a list of functions and arguments and use that information to run VBA code from the immediate window





      To prevent this, you can add the line Option Private Module at the top of each standard/class module as shown below:


      This code line isn't allowed in form/report modules. Place all 'mission critical' code in standard/class modules

      However, it would be far better to prevent ALL access to code in an ACCDE file

f)   disable the immediate window

      The Immediate window can be used to obtain the result of any variables / constants.


      This completely undermines many of the reasons for creating ACCDE / MDE files in the first place.

      Adding the line Option Private Module at the top of each standard/class module as shown above will make this more difficult
      However, it will not prevent it if the variable/constant names are known to the user

g)   block all access to the VBE (doing this would cover both the previous two points)

      Doing this would not prevent code running nor would it have any effect on legitimate activity by end users.

h)   prevent the shift bypass and special keys being re-enabled externally

      These are amongst the various security options that can be set in Access options.
      However, it is currently far too easy to undo these security options from an external database

i)    disable Access options


      Unfortunately, any changes made in Access Options can negate many of the security measures in use

j)   change the visibility settings of objects in ACCDE files

      Currently, object visibility for both ACCDB and ACCDE files from external databases depends on the external database settings.
      This allows users to circumvent much of the security added in Access options for the 'source database'.

      Whilst this feature can be useful in the development process for ACCDB files, I see no benefit in allowing this in ACCDE files.

      Instead, for ACCDE databases, the visibility of objects from external databases should be based on the properties of the 'source database' itself.
      In other words, if view hidden/system objects are unticked in the source database, these should remain inaccessible externally.

k)   limit the use of GetObject automation in ACCDE files

      Automation is a fundamental feature of Office programs and has huge benefits for developers and end users.
      However, it also provides one of the the main methods by which any Access database can be manipulated externally.
      Currently, it is impossible to prevent automation using GetObject. It would be very beneficial to set an option to block GetObject 'attacks' in ACCDE files

      However, I expect making such a change would be outside the remit of the Access team.



2.   Summary                                                                                                                   Return To Top

      In many ways, enforcing all the above would be similar to having ACCDR functionality with ACCDE files in full versions of Access.

      Implementing all of the above changes would have no detrimental effect on the ACCDE files that I distribute.
      However, I accept that other Access developers may not work in the same way that I do.
      Therefore, another solution might be to add each of these as optional features in Access options

      Alternatively, these could perhaps be added to a new 'secure' ACCDE file format - perhaps ACCDS?

      NOTE:
      The Access development team has no control over changes to VBA or Windows, both of which are managed by separate development teams
      In writing the above list, I believe none of the above requests, except item k), would impact on other development teams such as VBA or Windows

      Finally, and totally unrelated to security . . .

      Like many developers, I use overlapping windows display in ALL my databases.
      At the moment, I have to either set that option with each new database or use a template database with that (and other preferred) settings.
      I would like to be able to set overlapping windows as a default Access option. Currently this is impossible but would be easy to implement.

      I have requested all of the above changes but sadly, I doubt any of these will be implemented soon . . . and quite possibly will never be implemented.

      What have I forgotten? What (if any) disadvantages would any of those cause?
      I welcome any feedback to the above suggestions. Do let me know what you agree with and what you don't...



3.   Feedback                                                                                                                   Return To Top

      I would be grateful for any feedback on the article including details of any errors or omissions.

      Please use the contact form below to let me know whether you found this article interesting/useful or if you have any questions/comments.

      Please also consider making a donation towards the costs of maintaining this website. Thank you



Colin Riddington               Mendip Data Systems                 Last Updated 30 Apr 2022



Return to Access Articles Page Page 3 of 3 1 2 3 Return to Top