Encryption of ID and PWD

[Jay]

Does MS Access encrypt ID and password entered by user?

 

[TC]

The password is encrypted with DES, then the whole file (username +
encrypted password) is encrypted with RC4.

Why do you need to know?

TC

 

[TC]

For more information:
- go to groups.google.com;
- click advanced groups search;
- enter the following message ID (including the <..>s) into the Message ID
box:

<1051148800.358938@teuthos>

HTH,
TC

 

[Peter Miller]

TC,

For more information:
- go to groups.google.com;
- click advanced groups search;
- enter the following message ID (including the <..>s) into the Message ID
box:

<1051148800.358938@teuthos>

Two comments:

1) An easier way to point people to specific message ids on
groups.google.com is to just provide the url directly. For example,
you could have posted:

http://groups.google.com/groups?as_umsgid=<1051148800.358938@teuthos>

instead of the multi-step approach you gave.

2) In your point (2) in the message you mention, it would have been
good to note that not only are such techniques possible, but that they
require just seconds to apply. Almost all algorithms can be cracked
with time. Many encryption algorithms using common key lengths used
in desktop software can be cracked in hours using optimized, but
essentially brute-force attacks. To suggest an implementation can be
broken in non-publicized ways gives the reader no clue as to whether
there is a fatal flaw that allows a hacker to immediately bypass the
encryption, or whether its just that the key length is insufficient to
prevent a brute force attack that, while inconvenient to perform, can
be utilized against a sufficiently interesting file. I think most
readers are familiar with the latter risk, and are willing to accept
it. The former, though, is unacceptable for even trivially sensitive
files. It needs to be stressed that the encryption implementation
within Access is of this former and unacceptable type, which allows
for immediate bypassing of the encryption and as such should never be
used for any purpose where security is of any importance whatsoever.

I would add that this refers to data stored within Access databases,
and that it is not as relevant for when Access is used as a front-end
to a server rdbms like SQL Server or Oracle. Being able to decrypt
and desecure a front-end is still trivial, but the data is not as
directly at risk if it is not stored within Access/Jet files.


Peter Miller
____________________________________________________________
PK Solutions -- Data Recovery for Microsoft Access/Jet/SQL
Free quotes, Guaranteed lowest prices and best results
www.pksolutions.com 1.800.987.7716 1.619.839.3900

 

[Peter Miller]

Egad...

2) In your point (2) in the message you mention

....should have read 'In your point (3)'.


Peter Miller
____________________________________________________________
PK Solutions -- Data Recovery for Microsoft Access/Jet/SQL
Free quotes, Guaranteed lowest prices and best results
www.pksolutions.com 1.800.987.7716 1.619.839.3900

 

[TC]

Well, I don't disagree with any of that!

In point (2), I was not really referring to the "known key" thing. I was
referring to the mistake of using a symmetric cipher to encrypt the
passwords, instead of (for example) a cryptographic one-way hash. That
"schoolboy howler" mistake is what makes the passwords recoverable.

TC

 

[Peter Miller]

In point (2), I was not really referring to the "known key" thing. I was
referring to the mistake of using a symmetric cipher to encrypt the
passwords, instead of (for example) a cryptographic one-way hash. That
"schoolboy howler" mistake is what makes the passwords recoverable.

TC

My mistake. I said point (2) when I meant point (3).

Peter Miller
____________________________________________________________
PK Solutions -- Data Recovery for Microsoft Access/Jet/SQL
Free quotes, Guaranteed lowest prices and best results
www.pksolutions.com 1.800.987.7716 1.619.839.3900