Due to recent discussions in the microsoft.public.access.security newsgroup, it has become apparent that some people do not properly understand how Jet implements the various levels of security features that it offers.
Here I intend to explain everything in a clearer format. I won't be discussing Access-specific security features here (such as MDE file protection) - nor will I be providing the actual significant implementation details of the security methods offered – I will simply explain in brief form how each method works, ‘under the hood’.
JET MDB DATABASE FORMAT
ACE ACCDB DATABASE FORMAT
JET MDB DATABASE FORMAT
As you probably already know, there are three types of built-in security for Jet MDB databases:
- Simple database password.
- Whole file Jet encryption.
- User Level Security (ULS - also known as 'workgroup' security).
The most fundamental thing to understand is that all three of these security features can be bypassed very easily. There is no such thing as a secure MDB file – unless you look at using your own techniques to enhance the protection (not discussed here).
Now let's look at each of the built-in security options in brief detail;
1. Simple database password (Jet 3+ / Access 95+).
Jet 3: The database password, when set, is stored as plain text in the MDB file header.
Jet 4: The database password, when set, is obfuscated with a simple XOR pattern algorithm based on the file creation date/time (stored inside the file) which is then stored in the MDB file header.
Jet 3 AND 4: The MDB file header itself is further obfuscated with an XOR pattern – although its a constant XOR stream this time. (I describe these XOR encryption algorithms as obfuscation rather than encryption, given how simple they are).
When you open your MDB file, you are prompted for the password and then Jet can easily decode the original password to check it matches perfectly with the password that was entered.
- Password is easily retrievable since it is effectively stored in plain text (very simple obfuscation).
2. Whole file Jet encryption (also called 'encoding' rather than encryption in newer versions of Access).
When Jet encryption has been applied to an MDB file, the whole file (apart from the file header) is encrypted with the well known RC4 algorithm, using a 32-bit encryption key. The encryption key for the algorithm is a random key that is generated by Jet when you choose to encrypt the file. The generated encryption key is then stored in the file header (with the simple XOR obfuscation to try to avoid being easily detected).
- Simple to set up
- Prevents opening and modifying a protected MDB/MDE in a hex editor, although this is very easily overcome by the use of Serge Gavrilov's freely available decryption tool, 'MDB DeCryptor' that exploits the fact that Jet stores the encryption key inside the file header.
- The encryption key is _always_ available in the file header and therefore the file can be decoded very easily with Serge Gavrilov's decryption tool.
- Performance degradation due to whole file encryption.
- The resultant encrypted file is virtually uncompressable.
- Less chance of successful recovery if the file header is truncated when corruption occurs (we see a lot of cases like this)
3. User Level Security (ULS).
ULS offers a relatively easy way to manage multiple users accessing your database and configuring/restricting access rights to certain parts of your file for them users.
Under the hood, Jet uses a system table called MSysACEs in your main database file to identify what objects each user/group in your MDW workgroup file has access too (and what type of access they have). Jet enforces the restrictions at runtime by matching your user and group PIDs in the MSysACEs table.
- Simple way to manage multiple logins and basic access restrictions.
- The access restrictions you set to your data and objects are only enforced by Jet. If you use alternative software to open the file then you can gain full access to the data without worrying about ULS at all.
- Another way that I've seen exploited is a simple patch to the main Jet DLL which gives full access to the file by bypassing the access restriction checks that are in the Jet engine.
- Furthermore, there are numerous password crackers available for ULS.
Now the slightly confusing part is that when you use the Access wizards to setup user level security, Access also sets up Jet encryption for you at the same time.
Some people assume that because of this, your file is more secure but the truth is that since each of the three types of security are totally separately implemented in Jet, the result is not any better than each applied individually.
One might wrongly assume that due to having both ULS and Jet encryption set, Jet might not store the encryption key in the file header anymore and instead decode the key when the user enters the correct password for their account. This is simply not how it is implemented.
Given that each of the three types of security are easily by-passable individually, this also means that your file is no more secure when using a combination of ULS + Jet encryption.
- If you want a simple password check and are not that bothered about the real security of your file, then set a database password.
- If you want to decrease performance for no real reason other than to stop a limited number of novice Access users from modifying something in your file with a hex editor, then use Jet encryption. (You know those novice users that won't do a simple Google search and end up on Serge's site).
- If you want to setup multiple user access to your database then use ULS but beware that this offers little in terms of protection in the real world.
In conclusion, there is no real security for an MDB file, since each of the security methods have been exploited for years.
If you wish to learn how to actually implement these security features then consider buying the book 'Real World Microsoft Access Database Protection and Security' by Garry Robinson.
ACE ACCDB FILE FORMAT (ACCESS 2007)
The ACCDB file format offers less security features, but stronger protection than what's offered with MDB files.
User Level Security is no longer available for this file format. The only protection option is a combined Password + Encryption method.
The password is no longer stored as obfuscated plain text in the file header. Instead, a hash is used to check that the user has entered the valid password. The hash is generated from a combination of RC4 and SHA-1 algorithms.
Once the password is validated against the hash value, the password is then used to decrypt the RC4 encryption throughout the file.
The encryption strength itself has also been improved as the ACE database engine now utilizes the Crypto API and offers RC4 protection up-to 128-bit. By default though, files are encrypted with a 40-bit key. See http://www.everythingaccess.com/encrypt for further details.
The result is much improved encryption protection but at the cost of losing ULS. Having a single database password for all of your users is not exactly secure in itself. It is useful in a handful of scenarios though - just not very many.