FE + BE safe ?

823

Member
Local time
Today, 15:50
Joined
Jan 25, 2025
Messages
54
Hi at all,


I would like to know your opinion about how much safe is my FE + BE.
I try to explain:

With this forum's help, I've removed the shifkey at startup at my FE. (when Fe opens, It has a login form with password)
BE has a password I've setted in Access main options.
I've set also a password into VBA module.
If login is correct, there’s a vba code that check if file xxx is present into a determinate folder, if there isn’t that file the applications ends.

How much safe is my FE + BE ?

Some other thing to do to make them more safe?
 
Last edited:
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.
 
If everything is done through forms and users cannot see the Navigation Pane, and noticing your other comments, your DB is better off than many. If your users can see the navigation pane or directly interact with internal structure, not so good. However, "Access DB" and "safe" are words that usually do not go together very well. "Safer" or "Less safe" are usually more correct. Remember that Access was intended as a small business office tool. It does not have robust protection when compared to separate SQL engines such as SQL Server, ORACLE, or SYBASE.
 
Hi at all,


I would like to know your opinion about how much safe is my FE + BE.
I try to explain:

With this forum's help, I've removed the shifkey at startup at my FE. (when Fe opens, It has a login form with password)
BE has a password I've setted in Access main options.
I've set also a password into VBA module.

How much safe is my FE + BE ?

Some other thing to do to make them more safe?
You cannot really make an Access application 100% unhackable. You may have taken some steps to prevent non-advanced users from getting into the areas you don't want them to get into, but those steps won't stop the people with advanced knowledge of how Access works to get in, if they wanted to. What exactly are you trying to protect?
 
I forgot a thing:
If login is correct, the FE has a VBA code that check if file xxx is present into a determinate folder, if there isn’t that file the applications ends.
 
You cannot really make an Access application 100% unhackable. You may have taken some steps to prevent non-advanced users from getting into the areas you don't want them to get into, but those steps won't stop the people with advanced knowledge of how Access works to get in, if they wanted to. What exactly are you trying to protect?

First of all: the tables, then the db itself, if it will be copied into another pc (be+fe) it must not works!
 
First of all: the tables, then the db itself, if it will be copied into another pc (be+fe) it must not work!
It really depends on what you're trying to protect. If you're trying to protect the data, then even if someone copies the BE to another PC, they might still be able to get to that protected data.
 
You would not copy the BE to another PC.
The BE is shared by all users. They do have their own personal copy of the FE though.
 
It really depends on what you're trying to protect. If you're trying to protect the data, then even if someone copies the BE to another PC, they might still be able to get to that protected data.
Also if the BE is under password it is simple to access at table data?
 
It's possible if the FE is also available.
You’ve right! And this is why I’ve removed on FE shifkey + all navigation panels…
It is easyto enable shiftkey at FE ?
That’s why I would prefer a “personal” code that disable shiftkey than the access file that autodisable shiftkey, you have posted and I’ve used
 
You have seen how easy it is to change the allow bypass key, as that utility does it either way.?
 
Ok, so the weak of db “fe+be” is the easy way to enable shiftkey when Fe starts.
When fe is started with shiftkey all tables are visibles…
 
Ok, so the weak of db “fe+be” is the easy way to enable shiftkey when Fe starts.
When fe is started with shiftkey all tables are visibles…
Shiftkey only applies to code. It doesn't apply to tables. In other words, even if you have the Shiftkey disabled, someone might still be able to see the tables.

Again, what exactly are you trying to protect? Maybe we can tell you other ways to achieve it besides using the Shiftkey.
 
  • Like
Reactions: 823
Ok, so the weak of db “fe+be” is the easy way to enable shiftkey when Fe starts.
When fe is started with shiftkey all tables are visibles…

Yes. When using Access, you have to be prepared to accept "mostly secure" as a reachable standard because "absolutely secure" is available only when you turn the computer off.
 
Shiftkey only applies to code. It doesn't apply to tables. In other words, even if you have the Shiftkey disabled, someone might still be able to see the tables.

Again, what exactly are you trying to protect? Maybe we can tell you other ways to achieve it besides using the Shiftkey.
First of all: the tables, then the db itself, if it will be copied into another pc (be+fe) it must not works!
 
First of all: the tables, then the db itself, if it will be copied into another pc (be+fe) it must not works!
The tables are wide open, so copying them into another location wouldn't really stop them from "working." I mean, they are just data, so data doesn't have to work, they just have to show their values. For example, let's say I knew (or I got it somehow) the BE password, when I copy the BE to another PC and open it with the password, I should be able to view the contents of the table. Granted, I'll be looking at them as raw data without any "functionality" included, but I can still get to the data and then use them another way.

Having said that, what do you really mean when you said that the BE tables "shouldn't work" when copied to another PC?
 

Users who are viewing this thread

Back
Top Bottom