Jesse said:
Thanks for input thus far. I appreciate the time.
I see. In my case, I would want to encrypt every column of every table...
which would probably slow down and complicate the qry stmnts i would be
issuing from the front-end, no?
It would not necessarily complicate it all that much. For example,
instead of writing:
select person_name
from tblPersonDetails
where person_id = 45
you might write:
select decrypt(person_name)
from tblPersonDetails
where decrypt(person_id) = 45
But on reflection, it would probably defeat a lot of the query
optimization that the database does "behind the scenes". You'd have to
test it very carefully, to see whether you got adequate performance,
especially as it scaled with more records.
Maybe there is a way to encrypt the entire mdb file with a key that only my
application front-end (and myself - of course) know. Then, at start up, my
application could decrypt the entire file - incurring the penalty once, up
front; and my application would not need any further 'decryption code' as it
works with (querys/inserts into) the database.
Sure you could do that. And it would be the simplest method, because
you would not need any changes to the existing database queries or
code. But now there's something I don't understand - perhaps because I
haven't followed the start of this thread. Does the end-user have
access to the PC where the database is? If yes, then, the "decrypt
once" technique does not help; he just copies the /decrypted/ database.
If no (he doesn't have access to the PC), then, he can not copy the
database anyway, no?
And I'm not talking about
Access' 'database-level password' here because from what I understand that
password can be hacked even when the database is encrypted, right?
The database password, and even (unfortunately) the user level pwds can
both be hacked using various products. This is nothing to do with the
encryption (or non-encryption) of the database file.
HTH,
TC