Re: Protecting an Access Database
- From: "Nando" <nospam@xxxxxxx>
- Date: Sun, 12 Aug 2007 02:27:22 GMT
"Scott McDaniel" wrote:
On Sat, 11 Aug 2007 17:43:56 GMT, "Nando" <nospam@xxxxxxx> wrote:
"Scott McDaniel" wrote:
Nando wrote:
Any ideas on what to do to better protect the database after using ULS?
I
don't know what those unlockers do. Do those programs crack the Admin
password? Curious, because I want to make my database more secure.
Sometimes
db users (employees) have too much time on their hands.
The password crackers give you a list of all users in the database,
along
with their passwords. Once you have this
information, it's easy to log in as an Admin user and do what you want.
ULS is about as secure as you can get with Access/Jet. If you need
better
data security, you'll need to move to a
different database engine like SQL Server, MySQL, etc. Note that SQL
Server Express is free and is generally more secure
than Jet - although that's not always the case.
Thanks Scott! I see...So I guess that not even encryption (which I have
not
used yet) would have made the MDBs more secure.
If you mean the builtin Access encryption, then no, it won't make much of
a difference. With the builtin encryption,
Access will simply decrypt the data as needed when the database is open,
so if a user is actually able to open the
database, they'll see the unecrypted data. The only time buitin encryption
would be effective would be if someone
attempted to link to the database from another application (like via ADO)
... in this case, they'd see the encrypted
data.
You can build your own encryption routines and encrypt all data going into
the database, then decrypt as it comes out.
If you do this, then your data would be as secure as your encryption
routines. This would, of course, come with a price
re: performance ... encrypting and decrypting take time. This would also
mean moving to a fully unbound app, which can
take some time to create.
Hmm...that's sounds very good :) to have the encryption at the field-content
level. I like that! But using it will not only affect performance, but the
ability to use bound data-controls on forms. That would make application
development quite painful.
I think Microsoft could have created a built-in encryption function within
the VBA library to intercept the I/O, writing and reading of data in tables.
The function could have been initialized with a decryption key once a Access
session is started. This key (or password) could have been supplied through
the a user's VBA module and called at start up.
Either Microsoft don't care, "don't know," or seems to be just favoring
"marketing" rather than the application principle they once preached.
I'm just analyzing here, I like to thing about this kind of architectural
issues, not that this is a problem for me right now (but I know it will be
soon). I once wrote a client/server application using VB and SQL Server. But
sometimes (depending on the scenario and users) to have a server to host a
database is just extreme and non-possible. If the Access object model is as
flexible as thought, then perhaps there is a way one can intercept the I/O
of the data controls and implement an encryption function of my own. What
are your thoughts on all this?
.
- Follow-Ups:
- Re: Protecting an Access Database
- From: Scott McDaniel
- Re: Protecting an Access Database
- References:
- Re: Protecting an Access Database
- From: Scott McDaniel
- Re: Protecting an Access Database
- From: Nando
- Re: Protecting an Access Database
- From: Scott McDaniel
- Re: Protecting an Access Database
- From: Nando
- Re: Protecting an Access Database
- From: Scott McDaniel
- Re: Protecting an Access Database
- Prev by Date: Re: Protecting an Access Database
- Next by Date: Re: Protecting tables/queries from changes not in forms
- Previous by thread: Re: Protecting an Access Database
- Next by thread: Re: Protecting an Access Database
- Index(es):
Relevant Pages
|