IN THE SPOTLIGHT: MDE to MDB Conversion Service
(also supports: ACCDE to ACCDB, ADE to ADP, etc)
IN THE SPOTLIGHT: vbWatchdog
VBA error handling just got easier...
" vbWatchdog is off the chart. It solves a long standing problem of how to consolidate error handling into one global location and avoid repetitious code within applications. "
- Joe Anderson,
Microsoft Access MVP
Meet Shady, the vbWatchdog mascot watching over your VBA code →
(courtesy of Crystal Long, Microsoft Access MVP)
IN THE SPOTLIGHT: vbMAPI
An Outlook / MAPI code library for VBA, .NET and C# projects
Get emails out to your customers reliably, and without hassle, every single time.
Use vbMAPI alongside Microsoft Outlook to add professional emailing capabilities to your projects.
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’.
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.
- Simple to set up.
- 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.
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.
Have your say - comment on this article.
What did you think of 'Jet MDB security - under the hood'?
|David Plaut says...|
19 March 2009
User Level Security (ULS) is quite secure. Your article statements are incorrect. If you remove the admin user's rights from the security file other software can't get into the data.
|Wayne Phillips says...|
19 March 2009
Not true David, unfortunately.
Sure, you can make things a little harder for the novice users trying to break into your database - e.g. by removing the standard Admin user rights or perhaps having two seperate MDW files (one containing users/groups with design rights and the other not having any users/groups with design rights).
But you're missing the point. Any restrictions that you apply can be bypassed by using other software (other than Jet) to access the file data. For example - send your file to a data recovery outfit such as ourselves and you will see that we can access your data without any restrictions - that's because we don't use Jet to read your file data.
The main point to remember is that any ULS restrictions you apply are simply stored in a system table (called MSysACEs) and then enforced at runtime by the Jet engine. You can do as much trickery as you like with ULS, but you can't fix that fundamental implementation problem.
|Bob Sewell says...|
19 March 2009
I found this article very interesting and valuable.
I knew file passwords were a bit weak but didn't realise how weak.
I have used ULS in the past but found it very difficult to manage at remote sites and in the Citrix environment.
I currently use MDE files for Front Ends.
To block most villains I use passwords on Front Ends and Back Ends.
For user access I use a lttle MDE generally called START which links to a single table in the passworded Front End which then links to the passworded Back End.
Linking code is activated for the user if files move or I supply emailed updates.
User permissions for what they can and can't do is custom built for each application generally with 3 user levels, Admin, Normal and Read Only. I just plug the same permissions code and associated Logon form into each new application.
I know this method is not perfect but it will block all but the serious hacker from accessing tables, queries and code.
|Wayne Phillips says...|
19 March 2009
Bob, thanks for your input.
Indeed, the more unique that you make your security implementation, the better - in my opinion, anyway.
You're right - it's not perfect, but virtually nothing ever is in the cyber-security world (or in the real world for that matter).
It's a matter of degree - and I think you've got a decent balance there of easy implementation & reasonable security.
The best protection for Access front-ends is of course compilation to MDE format - which you are already doing. Good job.
Have your say...