Securely accessing an Access 2007 database...and are Access 2007 databases secure?

[clifgriffin]

I've written a password management application using .NET and c# that
stores several lists of passwords in a password protected Microsoft
Access database.

My first question is this...


1. Is Access 2007 security formidable? I know in previous versions,
there many utilities that would remove or reveal the password. How
easy is it to circumvent Access 2007's beefed up encryption?


I relied on the Microsoft model of handling database connections.
They
store a global connection string in the application settings, which
unfortunately includes a password. The problem with this, obviously,
is that you can simply run strings against the compiled application
to
find the password to my database in plaintext.


This obviously defeats the purpose of all the security and hashing
done in the rest of the application. This one little password gives
them access to all lists.


So my second question is...


2. Assuming access 2007 security is sufficiently hard to crack, how
can I obscure or encrypt the password for the database in my code
without having it directly related to user input. (Impratical since I
have multiple passwords.)


The solution does not have to be 100% unbreakable. We have more
layers
of protection than just this utility (including a windows account
password, and a fingerprint reader).


But it should be at least secure enough that someone cannot simply
run
strings against the binary to get the password to the database with
all of our other passwords.


Any ideas?


Thanks in advance,
Clifton

 

[Alun Harford]

I've written a password management application using .NET and c# that
stores several lists of passwords in a password protected Microsoft
Access database.

My first question is this...


1. Is Access 2007 security formidable? I know in previous versions,
there many utilities that would remove or reveal the password. How
easy is it to circumvent Access 2007's beefed up encryption?

It's probably trivial. People don't want serious security on their
office documents and simple databases - for most people it is more
important to ensure that they can recover their data when they forget
the password, than it is to keep out security professionals, police, etc.

A quick looks shows that there are already commercial products to attack
Access 2007 passwords.

I've not seen any academic papers on the subject - presumably nobody has
bothered to do an analysis.

I relied on the Microsoft model of handling database connections.
They
store a global connection string in the application settings, which
unfortunately includes a password. The problem with this, obviously,
is that you can simply run strings against the compiled application
to
find the password to my database in plaintext.


This obviously defeats the purpose of all the security and hashing
done in the rest of the application. This one little password gives
them access to all lists.


So my second question is...


2. Assuming access 2007 security is sufficiently hard to crack, how
can I obscure or encrypt the password for the database in my code
without having it directly related to user input. (Impratical since I
have multiple passwords.)

Well if you're talking obfuscation, keep in mind that anybody can use
reflector to get your code, run it and put a breakpoint when the
SqlConnection is instantiated. They can then look at your connection
string, no matter what fancy crypto or abfuscation you've done.

That would be the way I would attack your program - it's much easier
than pulling out strings and trying to figure out what they mean.

The solution does not have to be 100% unbreakable. We have more
layers
of protection than just this utility (including a windows account
password,

Not exactly great - ophcrack is pretty good these days, and Win2k
passwords (based on MD4) are on weak ground.

and a fingerprint reader).

Fingerprints are not secret. A fingerprint reader is a convenient way to
tell a computer who you are, but not secure.

But it should be at least secure enough that someone cannot simply
run
strings against the binary to get the password to the database with
all of our other passwords.

Any ideas?

A 'solution' would be to store the password to the database encrypted
with a key based on the user's password. Then you need the user's
password to decrypt it, and you can store an encrypted copy for each
user in your system. It's not perfect, but it's not totally stupid either.

Please remember that you don't know me and cannot reasonably trust me to
design your security system for you - I could be your adversary. The
same applies to everybody else around here.

I am a little concerned that you're designing and presumably
implementing a security application when your security knowledge is
weak... Maybe a commercial or open source product would better suit your
needs...

Alun Harford

 

[clifgriffin]

It's probably trivial. People don't want serious security on their
office documents and simple databases - for most people it is more
important to ensure that they can recover their data when they forget
the password, than it is to keep out security professionals, police, etc.

A quick looks shows that there are already commercial products to attack
Access 2007 passwords.

I've not seen any academic papers on the subject - presumably nobody has
bothered to do an analysis.









Well if you're talking obfuscation, keep in mind that anybody can use
reflector to get your code, run it and put a breakpoint when the
SqlConnection is instantiated. They can then look at your connection
string, no matter what fancy crypto or abfuscation you've done.

That would be the way I would attack your program - it's much easier
than pulling out strings and trying to figure out what they mean.


Not exactly great - ophcrack is pretty good these days, and Win2k
passwords (based on MD4) are on weak ground.


Fingerprints are not secret. A fingerprint reader is a convenient way to
tell a computer who you are, but not secure.



A 'solution' would be to store the password to the database encrypted
with a key based on the user's password. Then you need the user's
password to decrypt it, and you can store an encrypted copy for each
user in your system. It's not perfect, but it's not totally stupid either.

Please remember that you don't know me and cannot reasonably trust me to
design your security system for you - I could be your adversary. The
same applies to everybody else around here.

I am a little concerned that you're designing and presumably
implementing a security application when your security knowledge is
weak... Maybe a commercial or open source product would better suit your
needs...

Alun Harford- Hide quoted text -

- Show quoted text -

Well, there are a couple of very savvy security guys that will veto
the project if it isn't reasonably secure. Their best ideas included
tying the password to user input, but our current design makes that
annoying to implement.

The application is run from a secure terminal that is not on the
network and monitored 24/7 by two employees. A breach is fairly
impossible without inside help.

I just don't want this to be extremely easy to defeat.

Thanks for your ideas, I will go back to the drawing board again.
Clifton