FE + BE safe ?

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?
 
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
 
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?
 
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.
 
  • Like
Reactions: 823
@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.
 
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.
 
Last edited:
  • Like
Reactions: 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
 
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.
 
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.
 
Last edited:
  • Like
Reactions: 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?
 

Users who are viewing this thread

Back
Top Bottom