Re: use Windows EFS to encrypt access .mdb file???

From: TC (
Date: 01/20/05

Date: 19 Jan 2005 18:56:54 -0800

Your backend database is MS Jet, not MS Access:

VB <-> Jet <-> disk

I'm no expert on EFS, but I think that it causes data to be encrypted
(decrypted) automatically, at the last possible moment, before being
written to (read from) disk. This is done at the system level, not by
extra layers in the application (hence "Encrypting File System"). So
maybe EFS will do what you want. Using <-> to denote *unencrypted*
data, and <=> to denote *encrypted* data:

VB <-> Jet <-> {EFS magic <=> disk}

The advantage of that approach is that it might not need any changes to
your existing application. So, learn-up more on EFS, to answer your
question. Personally I would want to be certain:
- what needs to happen in order for Jet to be able to read & write the
EFS-encrypted data?
- what stops some other (evil) application doing similar things to read
& write that data?
- under what circumstances can the data be decrypted by someone with
elevated priviliges, eg. an administrator?

A second approach would be to modify the VB code to encrypt data before
storing it in the database, & conversely, decrypt it after retrieval
from the database. This is probably what the vendor has offered to do
for you:

modified VB <=> Jet <=> disk

The only other approach, as far as I can see, is to insert a layer or
wrapper between the unmodified VB program and Jet, or between Jet and
the disk (ie. file system). Those layers would not be using EFS. They
would use an open encryption standard such as AES:

VB <-> wrapper <=> Jet <=> disk
VB <-> Jet <-> wrapper <=> disk

Can such wrappers be written? Sure. But it would require a high level
of low-level windows programming knowledge to "hook in" to the relevant
method calls between the relevant modules. I know lots about Access &
Jet, and I've written hundreds of thousands of lines of code for them,
but I would have no hope of writing those wrappers.

Finally, if your application needs a key in order to decrypt the data,
then, a suitably motivated attacker could obtain that key (by reverse
engineering or other techniques) & thus decrypt your data. The only way
to stop this hapenning is to make the user enter the key whenever he
starts the application. And even then it's vulnerable if it is left in
deallocated memory, or copied to disk swap space, & so on ... :-)