Access File Security : MDB / MDE vs ACCDB / ACCDE

I’ve been going on about security in Access databases for some time.

Whilst there are many things that developers can do to improve the security of their applications (both design & data), 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

Attached is an article in PDF format (zipped) summarising the results of several simple tests I ran using a hex editor to view a variety of files.

The files are also attached if anyone wishes to repeat the tests
a) MDB.zip - Access 2003 MDB / MDE files with/without password protection
b) ACCDB.zip - Access 2010 ACCDB / ACCDE files again with/without password protection

In each case, the BE file has the password dinsdale. It contains 1 table with 2 records
The FE files are linked to this table. Where FE files have a password, this is MDS

In summary, for MDB/MDE files:
a) the password in a BE file can easily be read from the FE using a hex editor even if the FE is password protected.
b) the linked table fields & data can also be read even if the FE is password protected

For ACCDB/ACCDE files:
a) the password, linked table fields & data in a BE file can also be read from the FE using a hex editor UNLESS the FE file is encrypted with a password.
b) if the FE is password protected, the whole file is encrypted so nothing can be read by this method

I would appreciate any feedback on this article

The importance of the bottom line cannot be overstated:

However, an Access database can NEVER be made 100% secure. A capable and determined hacker can
break any Access database given sufficient time and determination

Click to expand...

If data security matters, the backend needs to be in a database server. No ifs, no buts. An Access backend file must be available to users and as such they may be able to copy and exfiltrate the file to break the security offsite at their leisure.

Having said that, ultimately if a user can see the data then it is at risk. The PCs on our domain even have their USB ports disabled to prevent files being taken away but there is no way to stop someone photographing the screen. There are stories on line of cases where data has been stolen in this way.

If data security matters, the backend needs to be in a database server. No ifs, no buts. An Access backend file must be available to users and as such they may be able to copy and exfiltrate the file to break the security offsite at their leisure.

Click to expand...

Agree totally.... though I had to look up the meaning of exfiltrate!
withdraw (troops or spies) surreptitiously, especially from a dangerous situation.

For info, I've updated the attached PDF file to include additional information about the security (or rather lack of security) for linked SQL tables in any MDB file format (including password protected MDE files)

For those who may not have time to read the PDF document, here are some screenshots which I hope are self explanatory:

Details of password protected MDE file in a hex (text) editor:


Details of password protected MDB BE file:


SQL Server BE details in password protected MDE file:


Hopefully these make it clear why no MDB/MDE data in a BE file can ever be totally secure if users have access to the FE file location.
They don't even need to know the FE or BE passwords to view the file using a hex editor.

For comparison, a password protected ACCDB/ACCDE file is fully encrypted and therefore much safer: