MDE application cracking issues

[aaron.kempf]

or stored procedures written with encryption... then you can mix and
match-- allow your customers to customize _SOME_ parts of your app but
not others.

Jet is ****ing stupid... move to SQL Server, kids

 

[Wayne Phillips]

I just can't see the point of writing code to encrypt/decrypt
strings in your MDEs when you can just do it the built-in way.

Before A2007, the encryption key was stored in the MDB file header. That
vulnerability lead to a simple (and free) tool appearing on the web that lets
you decode an encoded MDB file without needing to know anything about the ULS
that may be applied. Remember also that ULS and Access encryption are two
seperate things - however the two are usually applied together (e.g. when you
apply ULS, encryption is automatically applied).

Given the vulnerability (by design), the Access encryption is _very_ easily
reversed and therefore offers no real protection. Once the free tool is used
to decode the protected file, you would then be able to get in with a hex
editor and dig around freely.

In A2007 the difference is that the database password is now used as the key
to the encryption layer. Great, however in order to use the database you
need to release the password to your users... and therefore the encryption
can be removed easily by any of your users. Oh the irony...

 

[David W. Fenton]

=?Utf-8?B?V2F5bmUgUGhpbGxpcHM=?= <Wayne
(e-mail address removed)> wrote in

[quoting me, unattributed:]

Before A2007, the encryption key was stored in the MDB file
header.

Why would Access need to store an encryption key? You seem to be
confusing password protection (introduced in A2K) with encryption
(which was always part of Access going back as far as I'm aware,
i.e., Access 2).

That
vulnerability lead to a simple (and free) tool appearing on the
web that lets you decode an encoded MDB file without needing to
know anything about the ULS that may be applied. Remember also
that ULS and Access encryption are two seperate things - however
the two are usually applied together (e.g. when you apply ULS,
encryption is automatically applied).

I think you're completelly confused.

Given the vulnerability (by design), the Access encryption is
_very_ easily reversed and therefore offers no real protection.

The *password* protection is very easily reversed, but not the
encryption.

Once the free tool is used
to decode the protected file, you would then be able to get in
with a hex editor and dig around freely.

In A2007 the difference is that the database password is now used
as the key to the encryption layer. Great, however in order to
use the database you need to release the password to your users...
and therefore the encryption can be removed easily by any of your
users. Oh the irony...

Passwords have ZILCH to do with Jet encryption.

 

[Wayne Phillips]

Why would Access need to store an encryption key? You seem to be
confusing password protection (introduced in A2K) with encryption
(which was always part of Access going back as far as I'm aware,
i.e., Access 2).

No, I'm not confused at all. You are.

ULS security is TOTALLY independant of the 'encryption' Access uses. ULS
can be applied with or without encryption (you can remove the encryption part
with the encrypt/encode menu options after applying ULS). Similarly
encryption can be applied with or without applying ULS.

A little test for you... use the encrypt / encode menu option in the
Tools->Security menu on a new MDB database file (pre Access 2007) - this will
encrypt your file without ULS. Now close and open the file in Access... and
then tell me how Access decrypts the file without prompting the user for the
encryption key. I'll tell you how... because it stores the encryption key
in the file header.

Indeed, the encryption has been offered way back in Jet and hadn't changed
until Access 2007. Before Access 2007, the encryption is RC4 32 bit key and
in A2007 its RC4 with a 40-bit key by default (but can be increased in A2007).

I think you're completelly confused.

Erm... no, I'm not. You are.

The *password* protection is very easily reversed, but not the
encryption.

You seem so convinced that you are right, yet I _know_ I'm right.

Why don't you apply your ULS and then head over to Serge Gavrilovs site:

http://accesstools.narod.ru/

Download MDB DeCryptor and decrypt your file. Now open the file in a hex
editor... Suprise, suprise - the file no longer is encrypted.

Passwords have ZILCH to do with Jet encryption.

Again you are wrong.

In Access 2007 ACCDBs the database password you set IS the RC4 encryption
key (well a hash version of it).

You can choose to ignore me, or you can do a little more research and you'll
find everything I've said is correct. I'm the guy that offers database
repair services, MDE to MDB conversion services etc - believe it or not, I do
know what I'm talking about.

Wayne Phillips.
http://www.everythingaccess.com

 

[David W. Fenton]

=?Utf-8?B?V2F5bmUgUGhpbGxpcHM=?=

No, I'm not confused at all. You are.

ULS security is TOTALLY independant of the 'encryption' Access
uses. ULS can be applied with or without encryption (you can
remove the encryption part with the encrypt/encode menu options
after applying ULS). Similarly encryption can be applied with or
without applying ULS.

But if you don't encrypt, you haven't fully secured your data. If
you're trying to protect information from being read, you don't just
want to block access to your data through Jet, but you also want to
prevent someone with a text editor from pulling out data by just
reading in an unencrypted form.

So, yes, you can apply ULS without encryption.

But that doesn't secure your data unless you encrypt it.

A little test for you... use the encrypt / encode menu option in
the Tools->Security menu on a new MDB database file (pre Access
2007) - this will encrypt your file without ULS. Now close and
open the file in Access... and then tell me how Access decrypts
the file without prompting the user for the encryption key. I'll
tell you how... because it stores the encryption key in the file
header.

No, because the encryption key is stored in the Access executable
because it's the same for all databases.

Now, with passwords, yes, the encryption key is stored in the
database, because it *has* to be, since it's based on the password.

But for plain Jet encryption, there is no need for storing an
encryption key.

Indeed, the encryption has been offered way back in Jet and hadn't
changed until Access 2007. Before Access 2007, the encryption is
RC4 32 bit key and in A2007 its RC4 with a 40-bit key by default
(but can be increased in A2007).

And it's not stored in the MDB.

Erm... no, I'm not. You are.


You seem so convinced that you are right, yet I _know_ I'm right.

Why don't you apply your ULS and then head over to Serge Gavrilovs
site:

http://accesstools.narod.ru/

Download MDB DeCryptor and decrypt your file. Now open the file
in a hex editor... Suprise, suprise - the file no longer is
encrypted.

An encrypted file is not going to protect you if you aren't using
ULS (unless you're only using it to encrypt strings in the code of
an MDE). But if you are, they'll have to crack the ULS (which we all
know is easily done), and then they'll have access to your data with
no additional cracking necessary.

Again you are wrong.

We had encryption before we had passwords. Explain how that worked,
then.

In Access 2007 ACCDBs the database password you set IS the RC4
encryption key (well a hash version of it).

Yes. This is a changed, and a good change for those who find
passwords useful (I find them completely worthless).

But if you have an MDB and encrypt in A2007 without a password, the
password is not used as the encryption key, because, of course,
there *is* no password.

You can choose to ignore me, or you can do a little more research
and you'll find everything I've said is correct. I'm the guy that
offers database repair services, MDE to MDB conversion services
etc - believe it or not, I do know what I'm talking about.

And you don't seem to understand some very basic things about Jet,
which leads me to believe that I should never recommend your
services.

 

[Wayne Phillips]

But if you don't encrypt, you haven't fully secured your data.

Wrong. I've already made my point... Jet encryption does *nothing* to
protect your data as it can be completely reversed independantly of whether
you have applied ULS or not.

Did you even try out the previously mentioned tool on one of your ULS
protected files (and then looked at the file with a Hex editor)?

This is the basis of my whole argument with you here:

Stating that the encryption offers better protection when the encryption is
fundamentally flawed, is wrong. (Note that I'm talking prior to Access 2007
ACCDB file format here, obviously).

If you're trying to protect information from being read, you don't just
want to block access to your data through Jet, but you also want to
prevent someone with a text editor from pulling out data by just
reading in an unencrypted form.

Agreed. But Jet encryption is useless (prior to A2007 ACCDB file format)
for the reasons already explained.

So, yes, you can apply ULS without encryption.
But that doesn't secure your data unless you encrypt it.

But if you encrypt it (even with ULS), then it can be decrypted with ease
(using the tool aforementioned).

So what's the point in doing that? Jet encryption is flawed, so it's next
to useless.

It is better to look at other methods, like Tony has.

No, because the encryption key is stored in the Access executable
because it's the same for all databases.

No it is not. Stop assuming things. The encryption key is stored in the
file header.

The encryption key is randomly generated when you create the MDB file and on
subsequent compact & repairs.

It's a stupid argument since the effect is the same as if the encryption key
had been constant in the EXE ( - but it is not).

Now, with passwords, yes, the encryption key is stored in the
database, because it *has* to be, since it's based on the password.

But for plain Jet encryption, there is no need for storing an
encryption key.

And it's not stored in the MDB.

The encryption key IS stored in the file header. Again stop making
assumptions when you obviously know nothing about what you are talking about.

You are still not understanding that ULS has _no_ effect on Jet encryption.

Jet encryption is a completely independant layer of security and is not
affected AT ALL by ULS.

An encrypted file is not going to protect you if you aren't using
ULS (unless you're only using it to encrypt strings in the code of
an MDE). But if you are, they'll have to crack the ULS (which we all
know is easily done), and then they'll have access to your data with
no additional cracking necessary.

An encrypted file does NOT offer better protection if combined with ULS.
Simple.

Frankly, I'm tired of repeating myself.

We had encryption before we had passwords. Explain how that worked,
then.

As I have said far too many times here... the random encryption key is
stored in the file header (- did you get that?).

Neither database passwords, nor ULS passwords affect the encryption in
anyway. (apart from A2007 ACCDBs database passwords which I've already
explained)

Yes. This is a changed, and a good change for those who find
passwords useful (I find them completely worthless).

Me too. A point I also made in my first post. Worthless in the majority of
cases.

But if you have an MDB and encrypt in A2007 without a password, the
password is not used as the encryption key, because, of course,
there *is* no password.

When I said Access 2007, I meant ACCDB files, not MDB files.

If you use Access 2007 to encrypt an MDB file then it has the same effect as
encrypting it with Access 2003 (i.e. you do not benefit from better
protection).

It is the ACCDB file format that offers the better protection, not the
version of Access used.

And you don't seem to understand some very basic things about Jet,

It is you that does not understand some very basic things about Jet.

As an expert in recovering Access databases, over the years I've documented
the file formats completely.

I know exactly what every single byte of data in a Jet/ACE database is and
does. Can you say the same?

I think that puts me in a better position to comment than your good self.
No offence intended.

which leads me to believe that I should never recommend your
services.

I don't think I'll lose much sleep over that

Wayne Phillips
http://www.everythingaccess.com

 

[Wayne Phillips]

For more detailed info, see this article I've just put up:

http://www.everythingaccess.com/tutorials.asp?ID=185


Personally I am not bothered whether you believe what I write is accurate or
not. I know it's accurate - and that's what matters.

If you still think your approach of using ULS + encryption will stop a
determined person from reading/editing your file in a hex editor, then that's
your problem. I can only advise. Discussion over.

Wayne Phillips
http://www.everythingaccess.com

 

[David W. Fenton]

=?Utf-8?B?V2F5bmUgUGhpbGxpcHM=?=

[]

<plonk>