FE + BE safe ?

[Mark_]

Are you trying to lock your application to a specific processor or storage drive? Are you trying to make sure the program is not used after a "Lock out date"? Or are you trying to use a different approach to prevent unauthorized use of your software?

There are many ways to stop unauthorized use of software. Besides stopping shift-start from working, what else are you trying to do?

 

[823]

I need just to protect my data as much as I can
Nothing else

Anyway I think, in my case It should be already protected from a standard - normal user.

I asked only your opinion about this

Thanks

 

[theDBguy]

I need just to protect my data as much as I can
Nothing else

Anyway I think, in my case It should be already protected from a standard - normal user.

I asked only your opinion about this

Thanks

Are you the only user, or is it a multi-user application?

 

[823]

Multi-user application

 

[theDBguy]

Multi-user application

Then you must also trust the other users to protect the data as well. Good luck!

 

[Mark_]

In general, the safest way to keep end users out of your back end is to use network permissions to prevent them from accessing where your data is stored. If they do not have rights to the folder, they can't see or change anything. The front end is normally not useful if you don't have the data.

IF you are worried about a client doing something silly, that is a different question. Then you become worried about which server your system is installed on.

 

[The_Doc_Man]

@823 - there is a phrase we use in computer security - "low-hanging fruit" - which is when you have fewer security measures in place than some other sites on the net. If you are able to do so, put some barriers in the way (and from your comments in this thread, you ARE doing that). Lots of people neglect simple security measures such as having a network security system in place. Using smart routers and firewalls is also a good way to handle external hackers, though that is usually a decision for the higher bosses.

Hackers come in two major varieties. Targeted hackers know exactly what they want and will go to great lengths to get it. Browsing hackers look for easy targets - low-hanging fruit - and take what they can get. If you are lucky, you can make it tedious enough to make many hackers lose interest and look for lower-hanging fruit so that they choose to leave you alone.

Putting various protective measures in place will make your DB less attractive to the browser hackers because they have a short attention span. If you make them take too long, the browser hackers decide it isn't worth their time - which is exactly what you want. Particularly with Access, you can't stop the targeted hackers. You can only slow them down. But that is actually true for ALL DB systems, not just Access. When I was with the U.S. Navy as a contractor, we saw security patches coming in not only for operating systems but for network software, database management software, applications packages, and even security software. A recent scandal in the Solar Winds/Orion software was a targeted hack that hit the military very hard. (Technically, it was a Trojan Horse hack.)

Your concern over your own users is proper, which in operational terms means you must be vigilant and consider who among you could benefit from internal DB knowledge. Then watch those people slightly more carefully than other users. Dealing with internal security threats is a lot harder since the insiders presumably have passwords and network access through internal routers. The internal routers and firewalls assume you have a right to be there if you are already known to the domain or server or whatever you have protecting things. Something you need to consider is to know HOW you would detect that data HAD been stolen, since you are worried about it.

 

[AHeyne]

Is the frontend a accdb, or a accde?

 

[Josef P.]

A few thoughts on protecting an Access file backend:
An encrypted backend is generally a good starting point.
In my opinion, the problem in this case is not the backend, but the frontend.

Unfortunately, Access stores the password of the backend readably with the linked tables.
This can be avoided in the first step by linking the tables to an unencrypted backend (in the target storage path) and opening a connection to the encrypted backend once when starting the application. (Do not relink the tables, otherwise the password will be readable again in the frontend).

Unfortunately, this variant is only apparently secure, because as soon as you link another table in the backend from the outside in the frontend, the password can be retrieved again.

I am more in favor of an active DBMS as a backend system with Windows authentication (AD environment). Then at least I know that the data can only be read within the AD environment. With an active DBMS, you also have more options for protecting the data at DB level.

 

[823]

BE is password encrypted. Ok
The problem is that FE password is know by the client users, It is not possible to hide the FE password because the client users cannot work anymore on FE…. It is right?
It would be great if client users can do only the login into the Fe login form and work in the fe forms, but they didn’t know the fe password. But I think this is not possible

 

[823]

Is the frontend a accdb, or a accde?

accdb

 

[AHeyne]

So if you would deploy an accde instead if an accdb as the frontend you could make it more secure as it would not be possible to edit any code or forms/reports in design view.

 

[Josef P.]

It is not possible to hide the FE password because the client users cannot work anymore on FE…. It is right?

You could use a small application to start the client, which only starts the client with the password.
Login could possibly also be done in this application.

Nevertheless, the backend password can still be read via an open frontend as soon as a connection to the backend is open.

 

[823]

You could use a small application to start the client, which only starts the client with the password.
Login could possibly also be done in this application.

thanks Josep
Which applicaton hav I to use? ...how can I do?

 

[Josef P.]

You can create a starter application with the programming language of your choice.

I experimented a little with an encrypted frontend.

Main problem: I wanted to start an encrypted frontend as accdr (i.e. as runtime), but I can't do that via the starter application. It works as accdb or accde.

I also don't see any particular advantage with the encrypted frontend compared to a frontend (accdr) that only opens access to the encrypted backend when all security settings are set.
In both variants, the backend password can be read as soon as a connection to the backend is open.

My test files:

access-examples/app/CryptedFeBeStarter.zip at main · josef-poetzl/access-examples

Contribute to josef-poetzl/access-examples development by creating an account on GitHub.

github.com

a) open Starter.accdb for login and start of FE_crypt.
b) open FE_normal.accdb = frontend with login form to open connection to backend.

@all:
Is it possible to open an encrypted accdr file automatically?
The following does not work with an accdr, as the Access instance is also closed when CloseCurrentDatabase is called, because the runtime environment does not allow an “empty” Access instance.

ShellExecute 0, "open", """" & SysCmd(acSysCmdAccessDir) & "msaccess.exe" & """", """" & TempDbPath & """", vbNullString, vbNormalFocus
...
Set FeApp = GetObject(TempDbPath) ' TempDbPath = dummy file without database password
FeApp.CloseCurrentDatabase
FeApp.OpenCurrentDatabase FrontendFilePath, False, GetDbPasswordHash(...)

 

[Gasman]

accdb

Talk about shutting the barn door, after the horse has bolted.
It should be an accde at least. Even I gave my clueless users (as far as Access/coding went) an accde.

 

[Isaac]

we have some of these,
only certain users have permission to the folder (those needed)
the BE is 'hidden'
the BE can only be opened by certain admins.
the FE & BE have no shiftkey bypass.

so it's pretty safe from internal users.

I once got frustrated with what I perceived as a lack of total security for my DB back end, and decided on security-by-obscurity as follows:
- I wrote a VBA script to create , like, 100 levels of folders and subfolders, just named numerically. I then placed my BE in the lowest-most layer, because nobody would take the time to navigate down that far with random numbers and no visual cue as to how many layers were left to go!

 

[Mark_]

I once got frustrated with what I perceived as a lack of total security for my DB back end, and decided on security-by-obscurity as follows:
- I wrote a VBA script to create , like, 100 levels of folders and subfolders, just named numerically. I then placed my BE in the lowest-most layer, because nobody would take the time to navigate down that far with random numbers and no visual cue as to how many layers were left to go!

"dir /s *.ac*"

 

[Isaac]

Oh yeah, easy for a programmer but not for a user navigating by mouse

 

[Mark_]

So "Youth proofed?"