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 ... :-)

Relevant Pages

  • Re: DRA is Decrypting Files when it shouldnt be!!!
    ... Policy then the user's EFS files can be updated automagically to reflect the ... fact to attempt to decrypt EFS files for a user that does not have their EFS ... > you didn't go far enough, after you log in as the built-in administrator ... >> RA though I rebooted the computer after encrypting the files and before ...
  • Re: VS2005 website deployment problems with EFS
    ... It is not WIndows EFS, but it does encrypt. ... publish website or copy website deployment methods without manually ... If I manual decrypt the files then the manual copy the files it is quick as ...
  • Re: EFS Questions
    ... EFS: ... If someone encrypts files on their local computer (in a domain ... > based environment) and later needs to be decrypted by the FRA, ... Then I'm able to decrypt the files. ...
  • Re: EFS Certs in AD or local PC?
    ... If his profile is in AD and we import his cert, will he be able to decrypt ... The users EFS private key is stored in the user's profile but not in a way ... If there are no correct EFS private keys [user ... configured then the RA [usually built in domain administrator account] ...
  • Re: EFS Recover Agents Unable to decrypt files
    ... Permissions were checked to make sure that the EFS RA had full ... The EFS RA imported it's EFS RA certificate from storage in a secure ... I tried to decrypt the file after only importing the ... a special recovery key is created with the encryption process. ...