Re: Security - Is my way secure enough?



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.

--
Joan Wild
Microsoft Access MVP

Gino wrote:
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.


.



Relevant Pages

  • Re: SQL or Access DB
    ... As far as encryption goes though... ... with Sql Server you can use SQL DMO and encrypt your stored procedures ... installation - Security was absolutely critical and in most instances, ... > then we create a nice gui around this database and sell it to automotive ...
    (microsoft.public.dotnet.languages.vb)
  • Re: Cryptography in SQL Server 2000
    ... A company is vulnerable when its security ... > database encryption solution with protected key-management software ... > tested by the SQL Server Test Lab. ...
    (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)
  • Re: Which is more secure RC2 or RC4 ?
    ... form to place the order with their credit card. ... same database temporarily, until the order is approved manually and the ... If by MSSQL you mean SQLServer by microsoft, they got a security concept ... bothering about encryption, use microsoft's stuff for that and spend ...
    (sci.crypt)
  • Re: Newbie: Why dont I have Security on one of my drives?
    ... Show how LITTLE I know about security. ... If I go in and do any work on the database directly; ... Internet User permission on the database. ... >> I have three drives: ...
    (microsoft.public.sqlserver.security)

Quantcast