Updated 20 Jan 2022 Difficulty Level : Advanced
I have been writing about security in Access databases for some time in various online forums.
There are many things that developers can do to improve the security of their applications (both design & data).
However, no Access database can EVER be made 100% secure.
A capable and determined hacker can break any Access database given sufficient time and determination.
Recently, I’ve also stated on more than one occasion that the older MDB / MDE file format is FAR LESS SECURE than the newer ACCDB / ACCDE format.
Whilst this is hardly news to many developers, I’ve had a few requests to provide more details to justify this statement. An earlier version of this article was originally published at Access World Forums in response to these requests for additional information on security in different Access file formats
This article describes a simple way of comparing the security of the MDB & ACCDB file formats together with the compiled versions MDE & ACCDE.
To do this I used a hex (text) editor to view each of the files and examine the contents.
First of all, I created three very simple test MDB files in Access 2003 format.
1. A backend file BE.mdb with one table Table1. The table had 4 fields (ID, Surname, FirstName, YearGroup) and 2 records Ann Jones / Ben Smith
The BE file was encrypted with password dinsdale.
2. A frontend file FE.mdb. I then linked this to Table1 in the BE file
3. The frontend was copied, encrypted with the password MDS and saved as FE - PWD.mdb
Both versions of the frontend were then saved as MDE files: FE.mde & FE - PWD.mde
In early versions such as Access 97, password strings could easily be read from the file header section using a text or hex editor.
This appalling security lapse was fixed in later versions.
For more details on security features in different versions of Access, see Page 3 of this article.
I checked both the frontend and backend files using a hex editor and searched for the two password strings.
Although password data is stored in the file, the password information CANNOT be directly read using a hex editor in files.
NOTE: It is NOT necessary to know the database password to view the file in a hex editor
However, when I viewed the BE file using the hex editor, the details of Table1 were found unencrypted in several locations.
Both field names and the actual data were visible even though the file is password protected.
Password protected MDB BE file
For comparison, the entire file is encrypted in a password protected ACCDB file so the entire contents are unreadable.
Next, I wanted to see how secure the backend data would be from someone who only had access to the FE file.
To do so, each frontend file was then checked using a hex editor looking specifically for the BE password text strings PWD and dinsdale.
These were found in several locations:
Password protected ACCDB BE file
As you can see, converting the file to MDE format does NOT encrypt the linked table name or the password needed to open the BE file.
The BE file is completely insecure
Next, I checked whether adding a password to the FE had any effect.
Password protected MDB file
Password protected MDE file
The file location is also easily found:
Starting in Access 97, whole file JET encryption (AKA encoding) was also added as a separate security option.
The encryption is only 32-bit so is relatively easy to crack but it does offer additional security against casual hacking.
WARNING: During my tests I found that adding whole file encryption sometimes removes the database password! ALWAYS CHECK!!!
The above screenshots show that:
Adding a password to the MDB/MDE frontend does not in itself encrypt the linked table name or the password needed to open the BE file.
If you are using Access 97 or later, you should also separately encrypt the database
The contents of the BE file remain completely insecure UNLESS this is done.
However, each security measure in MDB/MDE files is applied separately and each is relatively easy to break.
Many tools are widely available to break MDB/MDE file security using external files, password cracks and MDE to MDB converters.
In the next section of this article, I will show the results of running the same tests on ACCDB/ACCDE files for comparison
Click this link to go to Page 2 or use the navigation buttons below.