encrypted database

[Adrian-Bogdan Andreias]

Hi guys,
I want to write an application that will be deployed on Windows 95 and
above.
Also I want to avoid distributing access drivers (AFAIK all Windows versions
come with a version of MS Jet driver).

And my question is:
Is there are a way to really protect the data in an access database. I know
that Access can have users and stuff, but I read somewhere on the net that
this user-level security is pretty easy to break.

I am looking for something as strong as PGP that is encrypting the database.
The thing is that I want to protect this database against the user that will
be using the database as well. The database must be accessed only through my
application.

Is it possible to do this with Access? If yes, can you give me a few ideas
about how strong security is regarding encrypted database?

And although I don't mind using Access 2003 or XP I would prefer a version
that has the necessary installed by default on a Windows 95 machine. And if
I have to distribute the Microsoft drivers I need an MS Jet driver version
that works on Windows 95.

I know there's always a way to break a security system, what I am looking
for is a rock solid database - disregarding the fact that the app it self
can be cracked and gain access to the database data.

Thank you,
Adrian-Bogdan Andreias

 

[TC]

(snip)

Also I want to avoid distributing access drivers (AFAIK all Windows versions
come with a version of MS Jet driver).

Access is a development product which is based on (and requires a
functioning copy of) the underlying database engine, MS Jet. Accces
certainly does not come with all versions of windows - it is an optional,
installable product. So if a target PC does not have Access, you will have
to install it from a product disk (just like any other application). It is
not just a driver or two!

Is there are a way to really protect the data in an access database. I know
that Access can have users and stuff, but I read somewhere on the net that
this user-level security is pretty easy to break.
I am looking for something as strong as PGP that is encrypting the

database.

There are products that will retrieve the usernames & passwords from a
secured database. So if that is not acceptable, Acces/Jet is not the product
for you.

The thing is that I want to protect this database against the user that will
be using the database as well. The database must be accessed only through my
application.

You can do that with Access/Jet, subject to the comments above.

I know there's always a way to break a security system, what I am looking
for is a rock solid database - disregarding the fact that the app it self
can be cracked and gain access to the database data.

Huh? Can you *accept* a scheme that can be broken, or can you *not* accept
such a scheme?


HTH,
TC

 

[TC]

Access is a development product which is based on (and requires a
functioning copy of) the underlying database engine, MS Jet.

Oops. Access of course does *not* require MS Jet. It can front to other db
stores, eg. MSDE, SQL*Server, Oracle, etc.

TC

 

[Adrian-Bogdan Andreias]

Hi TC,
Thank you for you reply.

It's just a bit of misunderstanding here. I want to use Access just for the
backend database and not as a development emviroment.

The application itself will be written in VC++. I'll need to distribute just
the *.mdb file and the application binaries along with the VC++ run time. So
I need just the MS Jet to access the database from Visual C++. So

Question (1): Does any Windows 95 installed OS has a MS Jet installed? If
yes what mdb file versions can be accessed (programatically from VC++
through ODBC). Can I open with ODBC a *.mdb file made with Office XP? (sure,
assuming that I am using just basci functionality that is available in all
Access versions).

Question (2): Is Access encrytion something to rely on?
I have read a few things in MS Access Security FAQ. And I realize that I
only need:
- (RSA) encrypted database
- a single password on the databse (no users or groups)
But can I be sure that noone with handy tools can crack the database and
read the data in it? Is this Access encryption + db password strong enough?
Let me remind me that I want the database to be accesible only through my
VC++ application using ODBC.

Thank you all for the feedback.

Regards,
Adrian-Bogdan Andreias

 

[Peter Miller]

The application itself will be written in VC++. I'll need to distribute just
the *.mdb file and the application binaries along with the VC++ run time. So
I need just the MS Jet to access the database from Visual C++. So

<sigh>

You need to distribute the application binaries, right, and you have
no problem with this, but you do not want to distribute the jet
library files - for what reason? Why not do what every other
developer does and make your setup image include the necessary dll's.
If they are not needed on a given system, then don't install them, but
if they ARE needed, your setup will have and provide them.

Question (1): Does any Windows 95 installed OS has a MS Jet installed?
Yes.

If
yes what mdb file versions can be accessed (programatically from VC++
through ODBC). Can I open with ODBC a *.mdb file made with Office XP? (sure,
assuming that I am using just basci functionality that is available in all
Access versions).

Sorry but this isn't really clear. You don't use odbc to jet under
normal circumstances, and although the functionality you seek may be
basic, this is not very relevant. Certain jet versions work with
certain db versions, and not others, and its not feature based. In
general, earlier versions of Jet can't work with later versions of db
(so any Windows 95 o/s with a then current version of Jet will not be
able to work with the most recent three versions of Access! Likewise,
the newest jet engine can not work with the oldest db versions (16 bit
v 1.0, 1.1 or 2.0 files).

Question (2): Is Access encrytion something to rely on?
No.

only need:
- (RSA) encrypted database

Actually its the RC4 algorithm - the same algorithm used by default
for browser security under SSL.

- a single password on the databse (no users or groups)

But can I be sure that noone with handy tools can crack the database and
read the data in it? Is this Access encryption + db password strong enough?

Not at all.

The db password is cracked in seconds with a couple of lines of code
(or just a manual edit). The encryption is virtually useless - not
because RC4 is weak (it is, but that's beside the point, and its
strong enough for the purpose at hand), but because it was implemented
in a terribly stupid fashion (the electronic equivalent of putting
your house-key under the welcome mat).

So Access encryption and the db password feature combined are
absolutely trivial to hack. User/Group security, if implemented
properly (ie, with the owner/super user users/groups not present in
the distributed workgroup) is a much better way to secure an Access
database, but this to can be cracked in minutes. It just takes a
little more know-how.


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

 

[Adrian-Bogdan Andreias]

Well, thank you for your reply.
Yes, you were right I haven't read enough

In the mean while I have read & found out about & downloaded ak_demo.exe and
it convinced me
It woorks on Acess XP! sh#$t!!

So we made a decision: since it is very important that our data must not be
available to user directly (without our app.exe) we are seriously analizing
the option of propertary format.

I guess by using crypto++ (an algorithm like IDEA from it) we can obtain an
acceptable level of security.

But than again the encryption key would be hardcoded in the app (visible or
not so visible ;-) ) and this could be cracked too.

But there's a difference between downloading ak_demo.exe and reverse
engineering the machine code and sweating through the asm code.

And it is a propertary format that is only used in obscure app, not Access
that is too known not be cracked (even if M$ would imrpove security by few
orders of magnitude).

Anyway, I am disappointed with Microsoft here. I have been using Access
(just elemtery stuff) as backup db for some years, but security (on db
level) wasn't needed until now.

BTW: please let me know if I wrong somewhere..

Thank you

 

[Peter Miller]

BTW: please let me know if I wrong somewhere..

No. You're not wrong at all.

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

 

[TC]

(snip)

The encryption is virtually useless - not
because RC4 is weak (it is, but

Er, that would be a surprise to the crypto community!

There's nothing "weak" about RC4 itself. It was their implementation
protocol that stuffed it up

TC

 

[Peter Miller]

Er, that would be a surprise to the crypto community!

No it wouldn't.

There's nothing "weak" about RC4 itself. It was their implementation
protocol that stuffed it up

I used 'weak' in two different contexts here - sorry if it was
confusing. The Access/Jet implementation of RC4 is hopelessly weak in
that it is trivial for someone with little to no understanding of
encryption algorithms in general to break, because the encryption was
implemented in a ridiculously stupid fashion. Encryption in Access is
not to be relied upon, and carries none of the strength generally
attributed to RC4 in other applications.

That said, RC4 is by no means one of the strongest encryption
algorithms out there. That is not at all relevant to discussions of
Access security, because the strength of the algorithm is the least of
the problems inherent in Access security, but it *is* indeed true that
RC4 is not considered one of the strongest algorithms by the crypto
community at large. I'm not sure what you base your claims about the
views of the crypto community on, but even the popular titles for
general audiences (take Schneier, for example) make clear that RC4 is
no great algorithm. Its utility and popularity comes from other
aspects than its strength.

So yes, Access security/encryption is weak and RC4 is somewhat weak,
but the former is so even for neophytes, while the latter is so only
in a general sense when comparing RC4 to other comparable algorithms.

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

 

[TC]

No it wouldn't.

Well, you should maybe tell that to:

o David Wagner, Assistant Professor of Computer Science, UCLA; cited in
legal actions regarding DeCSS as "a well-known and widely respected
researcher in the cryptography and security communities"
(http://www.cs.berkeley.edu/~daw/);

o Scott Fluhrer, commonly referenced as the "definitive source" of
information on RC4;

o Greg Rose, ex(?) board member of the International Association for
Cryptologic Research (http://people.qualcomm.com/ggr/index.html);

o Mike Amling, Mark Wooding, & all the other well-known crypto folks who
contributred to the following thread:

Ulrich Wurst, "Is RC4 a good choice?", 28-Jul-2003, sci.crypt

The general conclusion of that thread, slightly reworded, was as follows:
"RC4 is considered cryptographically secure, provided that three hygiene
rules are followed:
o The first 512 bytes of RC4's output must be dropped in order to defeat
weak-keys attacks;
o You should never use the same key twice; most protocols use a random
initialization vecton to avoid that restriction;
o No more than 2^30.6 bytes should be encrypted with RC4 (whatever the
key); this suffers from a distinguisher attack."

So it is just not true to say that "RC4 is weak".

I used 'weak' in two different contexts here - sorry if it was
confusing. The Access/Jet implementation of RC4 is hopelessly weak in
that it is trivial for someone with little to no understanding of
encryption algorithms in general to break, because the encryption was
implemented in a ridiculously stupid fashion. Encryption in Access is
not to be relied upon, and carries none of the strength generally
attributed to RC4 in other applications.

I'm not "confused" at all Here you correctly refer to the
*implementation* weakness. It is not the cipher that's weak. It is the
implementation that is weak. From a crypto viewpoint, those two things are
not the same.

Anyway, in my view, it is unfair to criticize microsoft for the crackability
of their RC4 implementation! They never said (AFAIK): "encryption prevents
the file from being deciphered except by an individual who has been given
the required decryption key". They said: "encryption scrambles the file so
it can not be read with a normal text editor or hex dump program". Again,
those two things are not the same!

When they *can* be criticized, is in the disgraceful implementation of the
password encryption! If they had done it properly (a change, I estimate, to
just *two lines of code*), it would never have been possible for anyone to
write a password decipherer - so we would all be much happier!

(snip)

Cheers,
TC

 

[Peter Miller]

Well, you should maybe tell that to:

The general conclusion of that thread, slightly reworded, was as follows:
"RC4 is considered cryptographically secure, provided that three hygiene
rules are followed:
o The first 512 bytes of RC4's output must be dropped in order to defeat
weak-keys attacks;
o You should never use the same key twice; most protocols use a random
initialization vecton to avoid that restriction;
o No more than 2^30.6 bytes should be encrypted with RC4 (whatever the
key); this suffers from a distinguisher attack."

So it is just not true to say that "RC4 is weak".

As I clarified in my second post, I was not saying it was terribly
weak - just that it was not a 'strong' algorithm all things
considered. However, its not an argument I'm seeking to push. I
mentioned it as an aside in my original post. The main point was that
the strength or weakness of the encryption algorithm never really
comes up because the implementation is so poor that no attack on the
underlying algorithm is ever necessary.

I'm not "confused" at all Here you correctly refer to the
*implementation* weakness. It is not the cipher that's weak. It is the
implementation that is weak. From a crypto viewpoint, those two things are
not the same.

Obviously, as I already stated.

Anyway, in my view, it is unfair to criticize microsoft for the crackability
of their RC4 implementation! They never said (AFAIK): "encryption prevents
the file from being deciphered except by an individual who has been given
the required decryption key". They said: "encryption scrambles the file so
it can not be read with a normal text editor or hex dump program". Again,
those two things are not the same!

Obviously, and I have no disagreement with the two statements (Msft
said one, and not the other). However, using a simple:

byte written = 255 - ascii_value_of_cleatext_byte

formula would also satisfy the simple claim made (ie, you wouldn't be
able to 'read' the file directly in a text editor or hex editor).
Where we differ, I think, is that I would not call such a formula
'encryption' in any normal sense of the word. Likewise, I would not
call Microsoft's use of RC4 'encryption' for, amongst numerous other
reasons, the fact that they violated the first two principals from
your expert's summary above (the first 512 bytes are *not* dropped,
and key *is* repeated) as well as the far more obvious flaw that the
key is in fact provided!

When they *can* be criticized, is in the disgraceful implementation of the
password encryption! If they had done it properly (a change, I estimate, to
just *two lines of code*), it would never have been possible for anyone to
write a password decipherer - so we would all be much happier!

Huh? This feature is obviously trash, and the addition of 'a couple
of lines of code' would have improved it, but it would still have been
quite weak. It was always a relatively lame idea, but its
implementation was ridiculously and stupidly flawed. Removing the
flaws wouldn't make it a reliable feature. It would simply have made
it 'weak' instead of 'bloody useless' and a joke.


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

 

[TC]

(snip)

Huh? This feature is obviously trash, and the addition of 'a couple
of lines of code' would have improved it, but it would still have been
quite weak. It was always a relatively lame idea, but its
implementation was ridiculously and stupidly flawed. Removing the
flaws wouldn't make it a reliable feature. It would simply have made
it 'weak' instead of 'bloody useless' and a joke.

Sorry, I wasn't clear. I'm referring to the user level passwords, not the
silly database password. As you doubtless already know, they encrypted the
user level passwords using a cipher (not a hash function) and a hidden
(secret) key. Thus, anyone who finds that key, can decrypt all the passwords
from a workgroup file. The products which do that are, in my opinion, the
real threat to access security - because they work, and are fairly freely
available.

If msoft had used a hash function to encrypt the passwords, it would be
impossible to reverse-engineer them, so products such as mentioned abve,
could not exist.

My reference to "2 lines of code", is this: although I obviously do not have
access to the Jet source code, I believe there is a *2 line fix* which would
solve the problem noted above! Then, it would not be possible to
reverse-engineer the passwords from a workgroup file. This, IMO, would be a
substantial improvement in the current situation.

I'll get off my a*s, write-up the suggestion in question, send it off, & see
what happens!

TC

 

[Lance]

Well, the pessimist in me thinks you would be wasting your
time. I really doubt your idea is something they don't
already know about or could have implemented a long time
ago. The bottom line (literally) is that improving jet
security would make it one less reason for people to
upsize to sql server databases. So in my humble opinion,
your not going to see that happen.

 

[TC]

Lance, Microsoft may well be a very large company, but they made some
absolute "schoolboy howler" mistakes with their cryptography in MS Jet. (If
you don't believe this, ask any professional cryptograher what they think
about the concept of reversible passwords...)

I have indeed come up with an idea which Microsoft almost certainly *has
not* thought of, for improving Jet security. It would be trivially simple to
implement, and it would instantly, permanently, and irreversibly destroy the
ability of any product to reverse-engineer passwords from a workgroup
information file.

I've started doc'ing this suggestion & will submit it to them in due course.
Whether they will even read it is, of course, a different question.

TC

 

[Lance]

TC,

You misunderstand me. I agree they have made some
mistakes, I don't agree with you that they don't know how
to fix them .

They are not going to fix them because of the reason I
stated in the previous post - money. If they make Jet
more secure they will lose some potential SQL server
licensing.

Maybe i'm wrong, I hope that I am.

Lance

 

[TC]

I doubt that many people upgrade for security reasons, compared to
volume/reliability issues. So an improvement in Jet security would not be
relevant to most upgraders. But that is just opinion, I have no actual
evidence for it.

TC