access back end needs to be secure

[Jesse Aufiero]

I intend to use an access file as the backend for my very data-driven vb.net
application. I need to secure this file so that it can only be access by a
user through the vb.net front end. How can I secure the mdb file so that no
one can look at it thru the 'back door'?

Thanks!

 

[Guest]

Generally, if you can get in through the front-end you can also get in
through the back-end.

First read the Access Security FAQ at
http://support.microsoft.com/support/access/content/secfaq.asp to learn how
to secure your database.

If you give users a login/password to access the system, anyone with the
know-how could log into the Access database directly. If you just hard-code
the login/password into the application, it can be cracked to find the string
where you store it and then they could still get in.

The best solution would be to follow the steps in the FAQ, create a new
group with minimal rights, and create users for that group that have a
login/password you can give out to whoever needs it. You can prevent those
users from having design permissions inside the database, but they'll still
be able to see the data (again, only if they know how to get into a secured
Access database).

 

[Jesse Aufiero]

Can you suggest an alternative to Access that is more secure?


"Phillip (formerly "theriaup")"

 

[Immanuel Sibero]

Jesse,

You can try MSDE or SQL Server Express (free download from MS).

Immanuel Sibero

 

[Jesse Aufiero]

I thought you might say that. I tried MSDE (I'm developing for version 1.1
of the .Net frmwrk) and had a number of problems installing it. It made me
wonder 'if I can't install it on my own machine manually, how will i deploy
it with my application!'.

 

[Immanuel Sibero]

of the .Net frmwrk) and had a number of problems installing it. It made me
wonder 'if I can't install it on my own machine manually, how will i deploy
it with my application!'.

Agreed. It's not the easiest. I think MS has a whole slew of information
(articles, documentation, etc.) on embedding MSDE/SQLExpress within your
applicaton. Personally, I have installed MSDE manually (painfully, as you
mentioned), but have never deployed it as part of an app.


Immanuel Sibero

 

[Jesse Aufiero]

MSDE seems like overkill anyway. The database size will not be large and
the sql stmnts will be relatively simple.

Access is a good solution in all respects except one: it doesn't seem secure
enough. There's got to be a way to store data outside my vb.net
application, query that data from my app, write data to that data source
from my app, and prevent hackers from accessing that data source directly.

 

[Rick Brandt]

MSDE seems like overkill anyway. The database size will not be large
and the sql stmnts will be relatively simple.

Access is a good solution in all respects except one: it doesn't seem
secure enough. There's got to be a way to store data outside my
vb.net application, query that data from my app, write data to that
data source from my app, and prevent hackers from accessing that data
source directly.

My standard advice... If the data needs to be secured form "users" then it
should not be in an MDB file.

Is this an app being run on a corporate network? If so SQL Server or MSDE
is not "overkill". What are the data security needs concerning the users of
the app? Whose data is it?

 

[Immanuel Sibero]

Jesse,

As long as you're considering standard commercial data format (i.e. mdb,
dbf, etc.), there's probably always going to be a back way.
Have you looked into encryption? I would think this might give you a whole
host of possibilities that would suit your need. You could encrypt the data,
the file, or both.

Immanuel Sibero

 

[Jesse Aufiero]

Access encryption is only as secure as the database password, no? If the
database password is cracked, encryption doesn't help much, isn't that the
way it works in Access?

If you're referring to some other kinds of encryption, I'm all ears as to
what they are. Are there methods outside of what Access provides that may
help me here?

 

[Jesse Aufiero]

clarification - i meant to say: 'are there methods of encryption outside of
what Access offers that will allow me to better secure an Access back-end?'

 

[TC]

He is saying that you could encrypt the data using your own additional
application code, before you stored it in the Access database. Then,
even if someone cracked the Access database, they would only get your
encrypted data - not your unencrypted data.

This could work quite well if you chose an appropriate cipher & ensured
that the cipher key was not readily discernable (eg. as a text string
within the database).

HTH,
TC

 

[Jesse Aufiero]

Thanks for input thus far. I appreciate the time.

I see. In my case, I would want to encrypt every column of every table...
which would probably slow down and complicate the qry stmnts i would be
issuing from the front-end, no?

Maybe there is a way to encrypt the entire mdb file with a key that only my
application front-end (and myself - of course) know. Then, at start up, my
application could decrypt the entire file - incurring the penalty once, up
front; and my application would not need any further 'decryption code' as it
works with (querys/inserts into) the database. And I'm not talking about
Access' 'database-level password' here because from what I understand that
password can be hacked even when the database is encrypted, right?

 

[TC]

Thanks for input thus far. I appreciate the time.

I see. In my case, I would want to encrypt every column of every table...
which would probably slow down and complicate the qry stmnts i would be
issuing from the front-end, no?

It would not necessarily complicate it all that much. For example,
instead of writing:

select person_name
from tblPersonDetails
where person_id = 45

you might write:

select decrypt(person_name)
from tblPersonDetails
where decrypt(person_id) = 45

But on reflection, it would probably defeat a lot of the query
optimization that the database does "behind the scenes". You'd have to
test it very carefully, to see whether you got adequate performance,
especially as it scaled with more records.

Maybe there is a way to encrypt the entire mdb file with a key that only my
application front-end (and myself - of course) know. Then, at start up, my
application could decrypt the entire file - incurring the penalty once, up
front; and my application would not need any further 'decryption code' as it
works with (querys/inserts into) the database.

Sure you could do that. And it would be the simplest method, because
you would not need any changes to the existing database queries or
code. But now there's something I don't understand - perhaps because I
haven't followed the start of this thread. Does the end-user have
access to the PC where the database is? If yes, then, the "decrypt
once" technique does not help; he just copies the /decrypted/ database.
If no (he doesn't have access to the PC), then, he can not copy the
database anyway, no?

And I'm not talking about
Access' 'database-level password' here because from what I understand that
password can be hacked even when the database is encrypted, right?

The database password, and even (unfortunately) the user level pwds can
both be hacked using various products. This is nothing to do with the
encryption (or non-encryption) of the database file.

HTH,
TC

 

[Jesse Aufiero]

The database would be stored on the users computer. But I don't want the
user to be able to hack their way in and see the data. Only my
application's front-end (coded in .Net) should be able to access the data.

Is their no way to make the mdb invulnerable to hacks? Or should they
change this newsgroup's name to microsoft.public.access.lackofsecurity ;-)

 

[Rick Brandt]

The database would be stored on the users computer. But I don't want
the user to be able to hack their way in and see the data. Only my
application's front-end (coded in .Net) should be able to access the
data.

Is their no way to make the mdb invulnerable to hacks? Or should they
change this newsgroup's name to
microsoft.public.access.lackofsecurity ;-)

No. Data that needs to be protected from *users* does not belong in an MDB
file. You can do many things to erect barriers for unsophisticated users,
but anyone with a few bucks who knows how to use Google can get into an MDB
file.

You could change the extension so it's not "mdb" and put it into a
non-obvious location on the drive and the user would likely never even know
where to look; again, depending on his level of PC knowledge.

 

[Jesse Aufiero]

Rick - you make a good suggestion. Thanks.

No. Data that needs to be protected from *users* does not belong in an
MDB
file. You can do many things to erect barriers for unsophisticated users,
but anyone with a few bucks who knows how to use Google can get into an
MDB
file.

You could change the extension so it's not "mdb" and put it into a
non-obvious location on the drive and the user would likely never even
know
where to look; again, depending on his level of PC knowledge.

 

[TC]

It depends what you mean by "invulnerable". Do you mean, for example,
invulnerable to someone who has access to a huge distributed computing
network, and can brute-force 56-bit keys in a few hours?

Security means nothing unless you say what threat level you need to
secure against. If you need to secure against the average user, Access
might do. If you need to secure against the NSA, Access probably would
not do.

HTH,
TC