Detailed QA explanation of Access security

Q MDB All the options of [Startup] are False and I start it with the cover form. Users in the same workgroup cannot open tables and modify them without authorization, but they can create another empty database and import or link to modify it. How? Prevention? Please enlighten me!

A First, you should use the MS Access Workgroup Administrator program to create your own MDW file, such as newSystem.mdw, and then create a new account such as newAdmin. The default ones are AMDIN and, such as GUEST accounts, and then set the password for each account. Then log in with the newAdmin account to create a database, or import tables or forms in an existing database for development. Set the security of the database. In addition to the newadmin account, all groups and users should be blocked from opening the database. Other permissions should also be blocked. This way it's safe. In this case, opening the database can only be associated with the newly created MDW file and can be opened using the newAdmin account. But in actual application, of course you should also create an account to run the software, such as newUser, (it is best not to use the default "user" account, so it is associated with SYSTEM. You can enter it on MDW, even if you set a password, it is not safe, because COPY a new SYSTEM. MDW can also be associated.) Set the permissions of the newUser account on each table accordingly. It can read and write, but cannot modify the design. It can only run the form. In short, it is used to run. Block all permissions that can be modified. In this case, there are two accounts for development and operation, but the new problem is that if it is handed over to the user, then the user must know the password of the newUser account. In that case, the data will not be safe, so VB or DELPHI should be used. To give a simple example, just write a sentence and run the database, for example: strRunShell = "c:Program FilesMicrosoft OfficeOfficeMSACCESS.EXE /nostartup"

strRunShell = strRunShell & "/wrkgrp c:newSystem.mdw c:pinewood.mde /user newUser /PWD yourpassword"
RetVal = Shell(strRunShell, vbMaximizedFocus)
Of course this is just a meaning. You can also write other things in this set, such as checking whether ACCESS is installed, whether the path is correct, and whether it is registered. etc. (Attachment: The above effect can also be achieved by using another database that has been compiled into an MDE file)

Q I have also used the user security group, but the security I am referring to is mainly for internal personnel. Outside experts such as Lin, don’t talk about it at all. Security is gone.
ACCESS has a fatal flaw (maybe I don’t know how to use it yet). Its security performance can only be used on databases with current security mechanisms. It is useless for users’ newly created databases. The user only needs to log in to ACCESS with his account. , create a new *.MDB, and then use the link function to link the tables of the back-end database (or the front-end database, because the tables of the front-end database are linked to the tables of the back-end database, it is nothing more than re-linking ), as long as he understands the contents of the table, he can modify it at will.
In fact, Microsoft slightly modified ACCESS to make its security mechanism applicable to all databases instead of the current database. We don’t have to worry about guarding against some novices. As our security mechanism is nothing more than preventing illegal modification and destruction by these internal users. .
So we need ACCESS system-level security mechanism or office developer edition which can also be helpful

A Wrong, wrong, "The user only needs to log in to ACCESS with his account, create a new *.MDB, and then use the link function to link all the tables in the back-end database (or the front-end database, because the tables in the front-end database The link is to the table in the back-end database, he is just linking it again), he can modify it at will as long as he understands the contents of the table. "
This sentence is wrong! If the security of ACCESS is really as good as what I said, then what I posted may be empty talk. You may still not practice what I said and posted. In fact, it won't be like that, because I created a newly created system file (i.e. MDW file), which is associated with the new system file to create a database, and the opening permission of this database can only be granted by the fixed user I specified, such as NEWUSER. , so others, no matter what system files they are associated with, cannot use the newly created database connection. If that were the case, ACCESS should have been eliminated long ago!
If you don’t believe it, I can make a database and send it to you to see if you can open it. I started using ACCESS for development in 1997. I have repeatedly tested various databases I have completed. If the situation you mentioned was possible, I would have accumulated dozens of databases developed by others that I want to crack. . . .
Q Create a new read-only workgroup and an ordinary user (without administrator rights), set no permissions for the system user group, then exit ACCESS, select the new MDW file, log in with the ordinary user, create a new file, and then You can import and link the previous database with a security mechanism.

A You may not have read my post carefully. In fact, there are more detailed instructions in the ACCESS help, which is very detailed. But in order to make you understand thoroughly, I will list the steps for fools. Don’t mind my dear brother, I also gradually became smarter after reading the help of fools.
1. First use the WRKGADM.EXE program in the ACCESS installation directory to create your own MDW file. Then connect.
2. After logging in to ACCESS, the default user is ADMIN. You can create an MDB at will, change the ADMIN user password, create a new account, such as PINEWOOD, for my future management, and then create a NEWUSER for my future users. use. (You don’t need to create any groups)
3. Log in again, log in as PINEWOOD, and then change the password, that is, change the empty password. Repeat for the NEWUSER account as well.
4. Log in with PINEWOOD, create the database MDB source file you need to develop, name it such as MYCODE and save it to set the security. You should know where the security settings are, they are in the menu. Block all ADMIN and GUEST permissions on MYCODE. Note that all permissions, whether they are on new tables, new modules, or opening permissions on the database, are removed. Then all permissions of all groups on this database are also blocked. Can't be left out. If the user group does not block its permissions, ADMIN and GUEST belonging to this group can open the database.
5. Then set PINEWOOD’s permissions on the database. Of course, all permissions should be available. Set the NEWUSER permissions. Of course, in addition to modifying the design permissions for all tables, queries, etc., you should have read and write permissions, open database permissions, and run permissions. In short, this account is for users.
6. Then do development, create table forms, etc. You've already done it, so import it. But at this time your database is safe and others cannot get anything from MYCODE. Unless you know the password.
7. After development, you should separate the database, not to mention whether you do this, and then make the background MDB database equally safe. Then compile the front-end program into an MDE file.
8. Make an EXE file. As I said in other posts, simply use the NEWUSER account to open the EXE file of the database. It is for your users so that they have no other choice but to use this EXE to use the database.
9. Then put the MDB on the server, and publish the MDE, MDW and EXE to users. Of course, the relationship between MDE and MDB is established and debugged in advance. It goes without saying how to deal with it in programming.
10. It’s enough to do this. For developers who really need security, there is still some work to be done. See my other posts. "Attention" said some things. Those questions will naturally be used if they are used, but those that are not used are still useless. Which problem should be solved? Do you think so?

Q Oh my God? ! ! Do I need to copy three files at the same time, mdb & mdw & exe???...
Not to mention that VB exe can be easily decompiled, wouldn't others delete the mdw file first and then open the mdb file? ?
If the security of access is limited to this, then it is really called "complete security".
Also ask, is there a more "safe" method that I need? The methods mentioned in the first two times can be solved by anyone with a little computer knowledge.

A For file sharing, the server only needs to install the MDB database, and the client needs to install EXE, MDW and MDE files.
Note:
1. It is an MDE file, not an MDB. The database should be placed on the backend, and the MDE file is compiled, highly efficient, and the source code will not be leaked even if the password is cracked.
2. If the user deletes the MDW file, then he will not be able to access the database at all. If he can access my MDB file without using my MDW file, then how can I talk about security?
3. It is not necessary to use VB for EXE files. VC, BC, and DELPHI can be used. Besides, I have not heard that versions above VB5 can be decompiled, and I have not found the corresponding tools.
4. There are currently many tools to crack the user-level security password of the ACCESS database, but it can be used by users of MDW files. Even if they crack the MDW file, they will not be able to obtain the permission to use the MDE source program file MDB. What's more, he can't get the MDE source program file MDB at all because it has not been released at all. Nowhere to get it, unless your computer is used casually. Therefore, the program is definitely safe. Although the security of the database data is relatively safe, it is still sufficient.

For more related articles, please pay attention to the PHP Chinese website (m.sbmmt.com)!