Hi Nick
TC,
You are absolutely correct. I wish I knew more about all of this security
hollabaloo, so I would be better suited for this job. Haha, and I could quit
asking so many dumb questions on these forums.
There are no dumb questions when it comes to security
AES? Sounds good - I'll see if I can look it up.
AES is the new US encryption standard. The previous one was DES. Both
of them are publically available in various languages including VB
(which is very close to VBA).
Both those ciphers are so-called block ciphers - not stream ciphers.
Stream ciphers suffer from a devastating attack (called the "known
plaintext attack") if you encrypt /several different messages/ (eg. CC
numbers) with the /same key/. You would avoid that attack by using a
different key to encrypt each CC number, or, by using a block cipher
instead. That's why I suggested AES - a block cipher. RC4 is a commonly
used stream cipher. So you would absolutely not want to encrypt several
CC numbers with the /same key/, if you were using RC4.
Though I'm curious about
your key construction comment. If I'm distributing MDEs anyway, isn't it a
bit redundant to contstruct the key with chr$(i)s?
I suggested that because I'm not sure whether strings like "ABCDE" are
stored verbatim in an MDE, or not. I suspect that they are. Say you
were using DES to encrypt the CC numbers. DES takes a 56-bit (7 byte
key). The attacker could just take each consecutive 7 bytes from your
MDE file, & try that as the key. If the key /is/ stored verbatim, that
attack would find it instantly; oops! So I always feel it is safer to
construct the key at runtime.
Another problem with MDEs, is this. An access database (mdb or mde)
contains a significant amount of uninitialized space within the file.
That space is used for buffers etc. at runtime. When Access creates the
mdb or mde file & saves it to disk, that space in the file is filled
with whatever is in memory at that time. >>> I have seen an MDE file
which contained, in that unused space of the file, some *source code*
from the VBA modules in that database <<< !! So in theory, part of
your sourcecode (containing the key generation expression) might
possibly exist in the file! There is no standard way around this rare,
but possible, problem. Access should, but doesn't, zero-out the unused
portions of the file, before it stores it on disk.
I just don't understand
how someone would go about hacking an Access MDE to begin with.
Remember that with CC numbers, you are primarily concerned with /data/
security. The MDE is for /code/ security. You could have an unsecured
MDE, in which case, your code is safe, but your data is open for all to
see.
When you decide how to proceed, I seriously suggest that you ask some
questions in sci.crypt. But be careful to do some research first. Also,
when you ask a question there, be sure to say what kind & level of
threats you need to defend against. Security means nothing, in the
absence of a definition of what threats you need to defend against. For
example, is my front door lock secure enough? YES to defend against a
passer by, MAYBE to defend against a burglar, NO to defend against a
locksmith or the CIA!
Hope this all helps,
Cheers,
TC
lol, it's almost