Last Updated 12 Mar 2022 Difficulty Level : Advanced
Section Links: Split DB Backend (BE) Frontend (FE) Other Security Password Encryption Server Based DB Downloads Security Challenges
This article is a companion to the following items at this website:
Access File Security Purpose of System Tables Security Challenges
As I have already written elsewhere:
Access databases can NEVER be made 100% secure
A capable and determined hacker can break any Access database given sufficient time and motivation.
However, by erecting various barriers, it is certainly possible to make the process so difficult and time consuming that it isn't normally worth attempting.
This article summarises some of the main steps that developers should take to improve security – it is not necessarily complete
Make sure you make several backups as you do each step as its only too easy to lock yourself out!
The second part of this article explains how to do each step with an example application containing the code needed
The third part of this article discusses a wish list of changes I would like to see added to ACCDE databases to further improve security.
Remember that Access apps (or any applications) are only as secure as the weakest part of the security used
1. Split your databases Return To Top
In a multiuser environment, Access applications should ALWAYS be split with:
a) Shared backend file(s) on the server and only containing tables
Users should connect to the backend files on a LOCAL area network (LAN)
- NOT on a WIDE area network (WAN) as it is likely to be slow and cause connection / corruption issues
NEVER use a cloud based location such as OneDrive or Dropbox as this significantly increases the risk of corruption.
Similarly users should NEVER run a split database when connected to the server using a WIRELESS connection
b) All forms, reports, macros and module code in a frontend database
Each user needs to have their own copy of the frontend database located on their own workstation
It is ESSENTIAL that users do NOT share the same copy of the frontend as corruption WILL occur
2. Backend files (BE) Return To Top
a) Hide all tables
b) Hide the navigation pane
c) Disable various Access options e.g. UNTICK all the following:
- allow full menus
- allow default shortcut menus
- use Access special keys (this disables the SHIFT bypass – but see below)
d) Do ONE of the following:
- Hide the ribbon
- Remove Privacy Options from the File menu (otherwise users can undo all the above)
e) Encrypt the BE, using a strong password. Do NOT store this password anywhere in the application (FE or BE)
There is no benefit in using an ACCDE file for the backend database if your backend database only contains tables.
3. Frontend file (FE) Return To Top
a) Do everything listed above to the frontend as well – no ribbon / no nav pane / shift bypass disabled etc
b) ALWAYS use an ACCDE so your code is compiled and therefore not available to end users
c) Rename as ACCDR and add code to prevent it being used if the file type is changed back again
d) Use strong encryption with a different password to that used in the backend file(s)
e) A VBA project password can also be used but it is easy to disable these. DO NOT rely on a VBA password alone!
f) It is strongly recommended that users login with user name & password:
- if possible do NOT store the passwords in the database - instead use Active Directory
- If you MUST store user passwords in the database itself, make sure you use strong 128-bit encryption such as RC4 (see below)
- Do NOT just encode passwords as doing that is usually very easy to decode and DO NOT:
- store the encryption cipher anywhere it can be viewed
- include decryption code in the database
- if you must store the encryption cipher in the DB, encrypt that as well (using a different method)
4. Other Security Options Return To Top
Other possible measures include:
- Add registry strings that are checked by the FE & if the settings are altered, prevent the FE running
- Using activation type code to 'lock' the application to a particular workstation and prevent copying
- Prevent users having direct access to the folders containing BE files
- Consider removing the taskbar whilst the application is in use but, if so, ensure that is reversed afterwards
It is possible for knowledgeable users to do ALL the following (and more) from an external application such as Notepad/Excel or another Access database
- re-enable the Shift Bypass
- view the connection strings to the BE tables (which exposes the BE password)
- change the start up form e.g. to bypass the user login form
- bypass everything on first opening if the location isn’t trusted
I am deliberately NOT going to explain how to do any of these things here
5. RC4 Encryption of Passwords Return To Top
The RC4 encryption code is freely available online and provides very strong 128-bit encryption - good enough for use in Access
However, RC4 encryption is reversible and is no longer considered secure enough for commercial databases storing information such as credit card data etc
For further details, see https://en.wikipedia.org/wiki/RC4
6. File versus server-based databases Return To Top
Access is a file-based application which is fundamentally why it can never be 100% secure
If you have mission critical data, an Access BE is NOT the right solution.
Using a server-based BE such as SQL Server will significantly improve the security of your data.
However, it does require someone with a good knowledge of SQL Server to maintain it.
7. Downloads & Further Reading Return To Top
Click this link for a detailed explanation of the various steps involved: Securing Your Database
The link includes an example application you can use for testing purposes
Click this link to download this article as a PDF file: Improve Access File Security
8. Security Challenges Return To Top
All the above security features (and more) are included in my various security challenges
Their purpose is partly fun but are also designed to encourage users to improve their own security by looking into weaknesses in other apps.
Each challenge is meant to be solvable so there are deliberate built-in weaknesses (as well as a couple of unintentional flaws included by mistake!)
I would be grateful for any feedback on this article including details of any errors or omissions
Colin Riddington Mendip Data Systems Last Updated 12 Mar 2022