Encrypt with password

[letsaccess]

Hi all,

I have a big access DB BE with 15 FE , I want to enable encrypt with password option in BE to secure the DB , is this procedure make any problem like disconnected or slow in FE users .

Thanks .

 

[CJ_London]

I wouldn't expect it to be any different to what they are experiencing at the moment, Note that once you have added a password to your backend, you will have to remake all your linked tables, you won't be able to just refresh them.

Also, be aware that the password will be in plain view to anyone who has access to the navigation window and a small knowledge of how access works.

You can make access more secure by doing things like hiding the navigation window, disabling the ribbon, bypass and special keys etc - plenty of threads on this subject in this and other forums, just google 'make access more secure' or similar.

However if security is a big issue for you, consider using sql server as the back end.

 

[letsaccess]

thanks but I read many article talking about face too much slow after encrypt with password and must open a table in background so I want to check is this true ?

 

[CJ_London]

I read many article talking about face too much slow after encrypt

what articles? can you provide some links? Don't confuse password protection with encryption of the entire file. With password protection the password is encrypted, but the file is not. Sure it takes say 0.1 of a second to decrypt a password, but that is minor compared with all the other processes going on.

must open a table in background

that goes without saying, password or no password. Actually it's not so much opening a table, as keeping the link to the backend open - which keeping a table open will do, but it is not the only way. And is why I said 'it to be any different to what they are experiencing at the moment' since if you are not doing that now, adding a password will have little effect on performance.

As with all these things - take backups and try it.

Equally, if not more important from a performance perspective is good table/index design and efficient forms and reports.

Things that can kill performance include using lookup/multivalue fields in table design, unnormalised tables and poor use of indexing. In queries use of union, group by and distinct (which can be indicative of unnormalised tables) and poor use of criteria (e.g. using an initial wildcard with Like, using 'having' rather than 'where' in group by queries). In forms/reports, use of domain functions like dlookup and form record/combo rowsources which bring through the entire table for filtering on form rather than using criteria to limit the recordset to be brought across the network.

 

[The_Doc_Man]

If you want to secure the DB and you have a domain-based environment with username and password or smart-card and PIN, you might get adequate protection from this method:

First, work with your domain manager to create a domain-level group name that will be used only for those people who will use the database.

Next, on the machine that hosts your back end, set aside a folder (but you probably have done this already) in which ONLY files related to your DB will be stored.

Now with the help of your security guru, change the permissions profile of the folder to allow MODIFY access to members of that group, but then take away access from all other groups and users. This means NO ACCESS to the Users and AuthenticatedUsers group and the Everyone group. Your domain person or security person can probably give you hints on any other groups and accounts you need to allow or deny for access.

You probably will have to still allow access to the System account, Administrators group, and Backup Operators group (if you have a regular backup regimen). There could be others required for your company's security profile, such as Auditors group (which in this case implies "Security Auditors") and possible some locally defined groups for your company's infrastructure. We would not be able to know about those.

The profile has to set the folder and all files and folders under it to have this protection. This is sometimes called "inheritance" of permissions. If you are currently sharing the folder for the back end with any other unrelated application, your best move is to split your app to its own folder, which simplifies the security setup tremendously.

Remember, once you give out the password, your people can see inside the database anyway. If you just decide who should be able to see this, let Windows do the user blocking for you. Be sure YOU are in the list of users but see next paragraph.

Now, here is one other thing to consider. You might want a second group that will have you and any other maintainer in it with FULL CONTROL profile rather than MODIFY profile. This will allow you to create new files and change their ownership to the group rather than you (the creator of the files).

Finally, add your users to the Windows group.

What this does is it grants users access to the files through their Group membership but not as casual users. This lets Windows enforce access rules. If your domain accounts require a login with username and password, let Windows do the work for you.

Other posts in this thread suggest searching for how to secure a database. If you find those articles, they will cover design of the app, code to disable features that give users too much power, and other ways to prevent users from getting "frisky." I'll leave that research to you. What I described is the Windows portion of what is needed.

By the way, the method I just described met the requirements of the U.S. Navy for a "Sensitive but Unclassified" database, and it was approved by a security manager after consideration of U.S. Department of Defense restrictions.