(E-Mail Removed) wrote:
> 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
Similar Threads
