Re: Protecting an Access Database



"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?


.



Relevant Pages

  • Re: Protecting an Access Database
    ... because I want to make my database more secure. ... I see...So I guess that not even encryption (which I have ... I think Microsoft could have created a built-in encryption function within ...
    (microsoft.public.access.security)
  • Re: Protecting an Access Database
    ... Do those programs crack the Admin ... because I want to make my database more secure. ... If you mean the builtin Access encryption, then no, it won't make much of a difference. ...
    (microsoft.public.access.security)
  • Re: Newbie - Is this Reasonable?
    ... because this hash is stored in the database. ... So you use PKCS5v2 to generate a key hash from a salt and the user's passphrase, then store the salt and the hash in a database. ... are even more critical in database applications because the payoff from tampering with selected fields may be much higher, fields tend to be fixed-length so it's easier to tamper with them in a meaningful way, and databases lend themselves to off-line analysis, so the attacker can marshall more resources and take more time to attack your system. ... You're using a stream cipher for encryption. ...
    (sci.crypt)
  • 2005-Problem restoring database with encrypted columns to diff ser
    ... I need to start encrypting several fields in a database and have been doing ... OPEN MASTER KEY DECRYPTION BY PASSWORD = 'testAppleA3'; ... ALTER MASTER KEY ADD ENCRYPTION BY SERVICE MASTER KEY; ... encryption by certificate test; ...
    (microsoft.public.sqlserver.security)
  • Re: How to prevent importing tables
    ... why in-built encryption doesn't even matter if they otherwise have ... off-topic but is all to do with security and "extraction". ... > sufficient permission to open the database, ... then they don't even need to decrypt it! ...
    (microsoft.public.access.security)