Security - Is my way secure enough?

G

Gino

A couple of weeks ago I was looking for suggestions on how to implement a
simple security strategy, mainly to prevent a backend Access database from
being opened/read if copied from the office to a home PC.

I did get some valuable suggestions (see at the end), mostly referring to
implementing the internal Access User Security system.
For now however, I am trying my own implementation of security and would
appreciate the feedback of this esteemed community on how my system could be
circumvented, beyond what I can foresee myself.

Of course I understand that if the FBI, banks, Department of Defense and
credit cards companies can get hacked, I would have no chance of preventing a
really determined and experienced fellow to actually penetrate into our
Access database.
Anyway below is the way I have implemented my security alternative for now:

1) Created a strong password on back end database

2) Encrypted the back end database (to avoid it being readable if opened in
hex editor or other program)

3) Connected the front end database to the tables on the now protected back
end database (which resides on the network drive.)
When the link is created for the first time, you must enter the password of
the back end database. The password of the back end database is stored in
clear in the front end database and is visible as text, if you open it in
notepad or hex editors.

4) Encrypted the front end database. The password to the back-end database
is not discernible any more. Then also added a password to the front end
database.

5) Changed the front end database to MDE and disabled the standard menus.
Then I disabled the Shift key startup bypass as well. This prevents the
standard menu to open thus eliminating access to the "Links Table Manager",
where the path to the back-end database would be visible.

The above, secures the database in so far that:
-If an employee copies the back end data base to his home PC, he cannot open
it due to the strong password.
-Importing the back end tables into a new database still requires the
password.
-If he uses an external program, notepad, etc the data is encrypted and not
readable.
-If the employee knows enough to copy both front end and backend databases
to his PC, the connection between the two cannot be established nor can it
be gleaned from the database itself, because of encryption.

(Typically in an office environment, the link to the back-end database would
have a path such as: T:\Netdrive\Data\AccessDB\Activities.mde. At home,
front end and back end would probably be both copied to the C: or D: drive
and would not connect.)
Of course if the user understands enough, he could reconstruct the path by
carefully browsing through network drives, file names, shortcuts etc. at the
office and then reproduce that environment on the local machine by trial and
error;
This quest however can be rendered more difficult at the office by hiding
drives, folders, setting permissions, etc.

Usability:
The application can be opened by simply entering the password to the front
end Access database. There is no message or indication that the back end
database is also protected by password/encryption.

Vulnerability of my approach:
I think that the main vulnerability of my approach lies in the password and
the encryption, which could probably be both cracked by brute force
decrypters, given enough time.
However this community may point out some other glaring weak areas that I am
blind to.
As always your feedback will be very much appreciated.

______________________________________________
Suggestions I had received:
1) Implement MS Access User Security.
Jack McDonald sent me a link to his excellent paper
http://www.geocities.com/jacksonmacd/ describing the whole issue of MS Access
security clearly and in detail.

2) Use a professional big boy database (Oracle).
I think that this would require a steeper learning curve than MS Access
Security -plus the additional cost of the software itself- but of course I
understand that this would really be very secure.

Thank you all.
 
K

Keith Wilby

Gino said:
5) Changed the front end database to MDE and disabled the standard menus.
Then I disabled the Shift key startup bypass as well. This prevents the
standard menu to open thus eliminating access to the "Links Table
Manager",
where the path to the back-end database would be visible.

What's to stop somone re-enabling the bypass key?

Regards,
Keith.
www.keithwilby.com
 
J

Joan Wild

With a search on the internet, a person can easily find a free database
password crack, and also easily find the code/utility to re-enable the
shiftkey.
 
G

geo via AccessMonster.com

Gino said:
Of course I understand that if the FBI, banks, Department of Defense and
credit cards companies can get hacked, I would have no chance of preventing a
really determined and experienced fellow to actually penetrate into our
Access database.

Most organizations are hacked because their security posture is extremely
poor - not because the hackers are all that good. It does not take an elite
hacker to re-enable the shift bypass key. Any kid with access to Google and a
bare minimum knowledge of VBA & Access can do it. The steps you have taken
are useful only because they keep incompetent fellow co-workers from mucking
up your database - which, now that I think about it, is actually very useful..
.. My advice is that you protect your Microsoft Access database files like any
other business data that reside on your organization's network. If you need
more security, you might want to look into Oracle or SQL Server or MySQL.

George
www.inspiredbrew.com
 
G

Gino

Thank you all for pointing out the weaknesses of my approach.
I thought that once the shift key startup option was disabled and the system
closed, it would not be possible to reenable it. I now understand that
somehow this may be possible by applying external code to the Access
application.

Sorry if I ask a stupid questions now: regarding the security of Oracle,
SQL, etc. which everyone acclaims, if it is based on a password, why would
that be less vulnerable to being decrypted than the same password when set in
Access?

Thank you again.
 
R

Rick Brandt

Gino said:
Thank you all for pointing out the weaknesses of my approach.
I thought that once the shift key startup option was disabled and the
system closed, it would not be possible to reenable it. I now
understand that somehow this may be possible by applying external
code to the Access application.

Sorry if I ask a stupid questions now: regarding the security of
Oracle, SQL, etc. which everyone acclaims, if it is based on a
password, why would that be less vulnerable to being decrypted than
the same password when set in Access?

Because Access designers did a bad job of making it difficult whereas the
designers of those other products did a good job of it.

There are also the problems that are inherant in protecting a *file* versus
protecting a *service*. A file can be copied and hacked away on at the
leisure of the hacker. A service can only be hacked on while you have
access to it.
 
G

Gino

Hi Keith,
thank you for your warning.
I thought that once the Shift Key bypass had been disabled and the Access
database shut down and restarted, there would be no way to reactivate it.
I understand now from various sources that external utilities could
reactivate the Shift Key and this would obviously expose the system.
Regards
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Top