Total Security

[Len Boorman]

I am aware that there area number of threads re security but this question goes a bit further.

I have been asked to secure an Access 97 Database such that absolutely nobody can get into it and examine, change,add,alter anything in any way at all.

So standard security is out since any mdw file could be overwritten with system.mdw.

Is it possible to get a compiler of some type that will produce an executable.

Import data to another database must also be impossible.

Sounds strange I know but there are good reasons for the request.

Comment, advice appreciated

Len B

 

[FoFa]

Use PGP to encrypt your mdb file. It uses 1024 encryption or something like that. Of course you have to decrypt it to use it and encrypt it again when done. Or if you don't want to by PGP, you can use WinZip to give a tough password to break, just make sure to MOVE instead of ADD when you zip it. Oh, and don't post the password on a sticky on the monitor.
Of course I do not suppose you have considered a secure network drive! It aint encrypted, but if access to the file is limited, do you need it encrypted?

 

[Len Boorman]

Thanks for comments.
Think I did not explain myself properly.

Point is that anybody can use the database. All menus, toolbars, databse window, bypass key either hidden or disabled.

But nobody can see or access in any way tables, queries or anything else. All anybody can do is to use the interface provided (Forms).

No additions, changes,deletions allowed by anybody.

In other words a working database that cannot be changed or added to in any way at all by anybody.

Len B

 

[Autoeng]

You are mistaken in the way that .mdw files work. If you create a unique .mdw file (not overwriting system.mdw) then only that workgroup file can access the db. It cannot be replaced by the system.mdw.

If you use access security with a few addins you can get to where you need to be. You will need to disable the shift key and hide the menu and toolbars. If you do these things in a db (not FE/BE setup) then the db will be secure to the specifications you have listed.

 

[RichardJ]

I wouldnt dismiss Access (.mdw) security straight away. For a start replacing a created security file with the standard .mdw file will not give anyone access to your database. It is possible to get hold of software that will rip a .mdw file and give up all the user names and passwords but your "standard" user would not have access to something like that anyway, and if your looking to protect your data from serious hackers perhaps you should be looking at using a different system or using Access security in conjunction with NT security or similar..

Good luck!

 

[IgorB]

To Autoeng:

Even if we disable all toolbars you still can import objects.
Also there is a way how to enable bypass to mdb again.....

 

[Autoeng]

You cannot import from a secured db. Read the MS security faq's to better understand security.

http://support.microsoft.com/default.aspx?scid=/support/access/content/secfaq.asp

 

[Len Boorman]

Many thanks for all of the replies. They are much appreciated. Re the comments on the mdw file. I appear to be mistaken but would appreciate confirmation that the following will not get around the security.

Say we have a database called ABC.mdb secured to a workgroup XYZ. This I believe would give XYZ.mdw.

So now
I rename XYZ.mdw to XYZ.old.
Copy System.mdw and call it XYZ.mdw and place it in the same location as the original mdw file.

Question
Do I now have a secured database attached to a workgroup ?.
What security now exists on the database ?.

Sorry for being pedantic but the database in question will go on individual standalone pc's to which I have no access. There is also obviously no possibility of using any network security.

Really appreciate the advice from you experts.

Regards

Len B

 

[RichardJ]

All security information is actually stored within the .mdw file.

When you create users and groups within the mdw you have to enter a 'PID' value. This value relates specifically to the user you have created.

You then use your created workgroup and set permissions to objects etc within your database.

Your access database will not only look for the user names but each user name will need to have the correct PID value that was used at the begining.

If you try and access a database, that has had its security limited via a specific workgroup security file, through any other workgroup file, you will not get access

 

[Len Boorman]

Thanks Richard.

I believe that the Built in Group Users will contain all users including new ones by default and the internal ID of the Users group is universal and identical in every workgroup. Additionally users cannot be disconnected from this Group. Permissions may be removed from this Group I agree

So I think that if I copy and overwrite the mdw file as described earlier then the permissions granted to Users i.e total will then become available.

I think then any security I originally created has become compromised.

Much appreciate your contribution. In this circumstance I am really trying to achieve a total lockout situation which is I believe extremely difficult and may well be impossible.

Regards

Len B

 

[Autoeng]

Len:

If you set up your users as described, yes you will leave yourself open to security breach. But the security faq very clearly describes how to set up security so this cannot occur. Make your own user groups, don't just throw everyone into the "User" group. It will help in granting specific access and will close the security hole that you descibe. Just to calm your concerns about renaming the security workgroup file locate it in a directory with no write, delete, overwrite permissions for anyone other than yourself. All that has to happen with the security file is that users have read permissions.

Total security is not impossible to obtain. I urge you to read the faq's. Then you will better understand.

 

[Len Boorman]

Autoeng
I have read a lot of threads on security and you obviously have a deep appreciation and understanding of the various security aspects which I respect and admire.

I believe that I understand the various aspects of groups and permissions but there is a final problem. Your last paragraph refers to locating the mdw in a secure location where only I have full access and everybody else has read only.

The database in question is likely to be located on stand alone pc's to which I have no access at all, Furthermore I will probably never know the machines on which the database is installed since they could potentially actually be anywhere in the world.

I really appreciate all of the replies to my question and the patience shown since I did not give a full picture of the circumstances under which this database will be used.

The question I am being asked is:-

Can I secure the database such that "most" persons could not add, change or delete any data item, function, process or design aspect of the application given that I have no control or access whatsoever to the network or machine on which the database is loaded.

by "most" persons I mean those with Access knowledge but no use of and cracker or hacking software.

I am not being deliberately difficult but I must reply to the question I am being asked and be in a position to accurately answer questions.

Again my appreciation to all

Len B

 

[Autoeng]

Len:

I included the part about locating the mdw file in a secured location so as to add to your security level. It is not necessary. Do you think that they would include a utility in Access and call it "Security" if there were ways to get around it? Access security, if implemented per the security faq's, in combination with a couple of other tidbits, is "total". Do you want me to make you a secured db and see if you can hack into it?

I don't think that you are being difficult but you don't have a knowledge of Access security of the other measures that I previously mentioned. Read the security faq's from beginning to end, yeah it's a long boring document, but it will explain how you will set up your groups so that the mdw file cannot be replaced. An important piece to remember is that the only thing stored in the mdw file is the users that are allowed to access the db. All of the form, table, report, query security settings reside in the db itself. If you don't believe me create a front end, back end db, secure it, copy it to another computer, then add another user to the FE on the development pc but don't copy the FE to the other computer. You will not be able to access the db on the other pc as the new user because the db rights themselves are in the db.

 

[Len Boorman]

Thanks Autoeng I will do as you suggest. Thanks again for the guidance.

len B

 

[Len Boorman]

Autoeng

Have done a lot of reading and have created a secured database (nearly) I think.

I have a couple of problems that I would appreciate your guidance.

Preventing use of Bypass key
I have used this before but within this secured database I get an error when logging on as a User. The error amounts to permissions on MSysDb object and specifically picks up db.Properties(AllowbyPassKey)=False.

Giving permission to User group on Database of administer cures the problem but I do not think this is really to way to resolve the diffilculty.

Edit Believe I have resolved this one my setting permissions on Sys Tables.

I also believe I have some user permissions wrong since if I join system.mdw I can import tables and queries (but not forms) from the secured database into a new database

Suspect the latter needs me to create new database and import all objects whilst logged on as member of admin.

Edit Have done this but does not seem to have had any effect.

It appears I can still open the secured database when member of system.mdw. Have checked all permissions for user Admin are removed

Second Edit
Resolving hitches gradually. Would appreciate any comments on above

Len B

 

[Autoeng]

Len:

It's the 4th of July and after a few Bud's I'll forgo any answer and again refer you to the faq's. Don't skim them, read the entire thing. If you implement per them you will have total security. If you have create the security schema as per the directions you should not be getting the problems that you are having (other than the bypass key problem which I don't think is related to security).

I am on a business trip next week then holiday for a week so unfortunately won't be able to help you out any further until July 21st when I retrun. Keep posting here and if you don't get a response try www.tek-tips.com (sorry Jon to link to another Access forum).

 

[Len Boorman]

AutoEng

Got there.

Security is exactly as I wanted and as you said it can be done after reading the faq very carefully.

All questions resolved.

Next time I am your way the beer is on me.

Len B

 

[Autoeng]

Len:

Glad I was able to convince you to keep trying. I find that reading the faq's cover to cover is where most people limit themselves on knowledge of the utility. It's a long document but skimming over it can really screw you up.

Consider yourself to now be an Access security expert. I'll gladly share the duties of answering security questions with you.

And the beer? Gladly.