First Published 12 Mar 2022 Last Updated 30 Apr 2023 Difficulty Level : Moderate
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?
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