Doubts with access security

[Mylton]

Góis morning


These doubts became more evident to me from the need to learn, to look for literature and/or “more basic” examples.

These doubts became more evident to me from the need to learn, to look for literature and/or “more basic” examples.

Essas dúvidas ficaram mais evidentes para mim pela necessidade de aprender, de buscar na literatura e/ou exemplos “mais básicos”.

These doubts became more evident to me based on the need to learn, to look for “more basic” literature and/or examples.

Essas dúvidas ficaram mais evidentes para mim a partir da necessidade de aprender, de buscar literaturas e/ou exemplos “mais básicos”.



And I refer to basics as being a kind of school or colleges or books, where you can read understand and practice.

But I see myself a bit lost with a lot of information without understanding why.

This became clear to me when I read this thread

Replacement Switchboard

This Switchboard form is based on the last VBA version which I think was A2k. I expanded it to allow for 12 items rather than 8 and you can easily change it to do more. I've included directions. This updated version has two switchboards. One more traditional and the other is big buttons...

www.access-programmers.co.uk

And there…

I'm here asking for some of your knowledge so that I can walk more firmly in this universe that I learned to like and relax my mind.


Because this question is more related to coding, I put it in this topic, if it is not ideal, I apologize.



We know that access to other DB does not have the same security, so some people create mechanisms to make access difficult and prevent copies of the App.

I know there are some examples on this site and others out there.

But I would like to learn a little more.

Obtain literature to remove so many doubts.

That's why I'm here.

If anyone can give their opinion I would be grateful.



We have the question of encrypted login which would be easier or better or secure? 256? 128?

I noticed that at login some use a standard security type level 1, 2 and 3.

Why these three levels and not more or less?

If we adopt a login for activities or departments, how can we integrate this with the login when the person enters?

Like so-and-so who belongs to the secretariat only accesses records.



If we could integrate this into a mechanism of who came in and did what, would that be ideal?



Finally, regarding copy protection.

Is this idea of limiting by number of records in a key table bad or crazy? Where, when reaching this limit, would you leave all the buttons disabled only enabling them when you entered the code?

All by code ok?

Is it illegal or easy to get around?

If easy how do they do it or how do we prevent it?

Whether illegal? Why?



Thank you all for the teachings.

Thanks.

 

[Mylton]

Gois
= good

thanks

 

[jdraw]

Check this by Isladogs as a starting point. He has several posts and a website dealing with Access and "security".

 

[Mylton]

Ok
Thanks.
Happy New year

 

[The_Doc_Man]

Some years ago, back around Ac2000 or Ac2003, we still had User Access facilities where a user would log in and some permissions would be attached to various database objects. It was called MDAC, Microsoft Data Access Control, and it worked... but not very well. It turned out to be highly susceptible to people "spoofing" logins. Not much later after that time, MDAC was quietly removed as a facility. The .ACCDB and related formats do not support it at all.

The base philosophy of Access has changed back to its original concept of being a small-business utility where you would be talking about a small number of users, 5-10 being common. Access now provides you with tools so that you can try to protect your data in various ways, but the really sensitive applications use Access as a front-end only. They use some type of SQL active engine like SQL Server or ORACLE Enterprise Server as the back-end data driver. Those advanced back-end DB engines then take over the security issues - far better than MDAC ever allowed.

Therefore, @Mylton, if you are trying to secure & protect your data, search this forum for "Securing a Database" because that topic has been a popular point of many threads. I hope you can find what you need somewhere among these threads.

 

[isladogs]

Check this by Isladogs as a starting point. He has several posts and a website dealing with Access and "security".

Unfortunately the link in post #4 of that thread is out of date. The current link is

Encrypted Split No Strings

This example app shows how an Access database can be made reasonably secure against hackers whilst still allowing full functionality to authorised users.

isladogs.co.uk

 

[jdraw]

Hmmm... I just can't keep up with your links.

 

[isladogs]

Hmmm... I just can't keep up with your links.

Your link to my website was fine! The link in that locked thread was to my old (now defunct) website!

 

[Mylton]

Thanks.
I'll read.

 

[Pat Hartman]

Your question is not focused. What is the purpose of securing the application? Are you worried about the data? Are you worried about someone accidentally/deliberately breaking the code? Are you trying to protect your intellectual property?

The answer to all three is to use a different product. In the first case - data. Sensitive data should never be stored in a Jet or ACE database. It should be stored in SQL Server or some other more robust BE. You can still use an Access FE to provide the interface though. If you are worried about hacking, Access FE's solve only part of the problem, compiling and creating an .accde will prevent someone from accidentally modifying forms/reports/code but it will NOT stop them from modifying queries or macros or keep them from linking to a different database. If you are talking about protecting your intellectual property, you can make it annoying to crack your FE but you can never make it impossible given the type of file an Access database is.

 

[Mylton]

Your question is not focused. What is the purpose of securing the application? Are you worried about the data? Are you worried about someone accidentally/deliberately breaking the code? Are you trying to protect your intellectual property?

The answer to all three is to use a different product. In the first case - data. Sensitive data should never be stored in a Jet or ACE database. It should be stored in SQL Server or some other more robust BE. You can still use an Access FE to provide the interface though. If you are worried about hacking, Access FE's solve only part of the problem, compiling and creating an .accde will prevent someone from accidentally modifying forms/reports/code but it will NOT stop them from modifying queries or macros or keep them from linking to a different database. If you are talking about protecting your intellectual property, you can make it annoying to crack your FE but you can never make it impossible given the type of file an Access database is.

thanks.

I really feel lost.
but 1. the idea
would prevent copies and use after evaluation time.
2. to control who does what in the app.
3. Your switchboard example is trying to integrate a login and open a menu according to the employee's department. I would say that I am advancing at a slow pace.
4. I already thought of using a BE in sql but this should also be installed on the person's machine and as my idea is for use in small offices with 1 secretary and 1 or 2 medical colleagues, I don't know if there is any way to do the installation and sql configuration automatically.


anyway thanks everyone for the tips.

 

[The_Doc_Man]

Regarding your concern #2 (control who does what)...

If you look up "Securing a Database" you will see one very important tip: NEVER show the "innards" of the DB to the users. ALWAYS use some kind of dispatcher form that has as its only purpose that you click something to launch a given function. You NEVER let the users see the navigation panel, tables, queries, etc. in a "raw" setting. You make it so that no one sees enough of something to let them open a code module, query, table, macro, form, or report in design mode. The moment you have a design-level intruder, all of your concerns have become your worst nightmares.

IF you have control over what folks see from the front screen, THEN you can use role-based tests based on the login information. When you define a valid user, have a field in your user table to show what role they play - DBAdmin, Supervisor, Clerk, Grunt, whatever... Then you have the dispatcher form and it can decide (after the login) exactly what the logged-in person is allowed to do and see. Plus, if there is a data dependency, you can use the Form_Open as a 2nd-line blocker (since Form_Open can be canceled to block access to its functions) or Form_Load to selectively disable certain features and to assert a data-centric filter if appropriate.

In a small environment, your concern over the complexity of installation is valid. Just remember that to set up something complex involving permissions, you might need to have a designated administrator who is computer-savvy enough to understand how to apply your instructions to their environment. You are looking at a front-end / back-end system, so that means at least one machine will be different from the others. You will also have to assure that a LAN setup is involved, as otherwise only one machine will be able to do anything.

 

[Mylton]

Regarding your concern #2 (control who does what)...

If you look up "Securing a Database" you will see one very important tip: NEVER show the "innards" of the DB to the users. ALWAYS use some kind of dispatcher form that has as its only purpose that you click something to launch a given function. You NEVER let the users see the navigation panel, tables, queries, etc. in a "raw" setting. You make it so that no one sees enough of something to let them open a code module, query, table, macro, form, or report in design mode. The moment you have a design-level intruder, all of your concerns have become your worst nightmares.

IF you have control over what folks see from the front screen, THEN you can use role-based tests based on the login information. When you define a valid user, have a field in your user table to show what role they play - DBAdmin, Supervisor, Clerk, Grunt, whatever... Then you have the dispatcher form and it can decide (after the login) exactly what the logged-in person is allowed to do and see. Plus, if there is a data dependency, you can use the Form_Open as a 2nd-line blocker (since Form_Open can be canceled to block access to its functions) or Form_Load to selectively disable certain features and to assert a data-centric filter if appropriate.

In a small environment, your concern over the complexity of installation is valid. Just remember that to set up something complex involving permissions, you might need to have a designated administrator who is computer-savvy enough to understand how to apply your instructions to their environment. You are looking at a front-end / back-end system, so that means at least one machine will be different from the others. You will also have to assure that a LAN setup is involved, as otherwise only one machine will be able to do anything.

I agree
I even managed to make a "kind" of model, where an ID of 1 would open a specific menu screen.
my difficulty is that everyone who had that ID., with that menu, would only open that menu. but I don't know if this is correct and how to improve.

As for protection...
Do you think it's valid for the buttons to be inaccessible by coding?

anyway...
many doubts.

But I learned that slow is also fast.

 

[Gasman]

My approach has always been to show only what the user is allowed to see.?

Not to show everything, and then say an item is not allowed when selected.

Create a userlevel(group) where everyone in that group has the same access. Then restrict on those levels.

 

[Mylton]

My approach has always been to show only what the user is allowed to see.?

Not to show everything, and then say an item is not allowed when selected.

Create a userlevel(group) where everyone in that group has the same access. Then restrict on those levels.

I will try to gather all my ideas and see if I can produce an example.

but anyway...
thank you all for your help and learning.

 

[The_Doc_Man]

Do you think it's valid for the buttons to be inaccessible by coding?

I did exactly that for one of my bigger projects for the U.S. Navy, in that only a person who had the "system administrator" role could see the CREATE button (to create a new system for a project.) Only a project manager could use the CREATE button (to create a new project to which resources could be added)... and so on. In each case, the Form_Open event determined the user and verified roles & privileges. The Form_Load event had access to and could therefore hide or reveal particular buttons. For cases where someone was updating a server, the Form_Current event could see whether the user was allowed to touch the particular server and modified the AllowEdit (and related properties) as required. So do I think it is valid to use VBA to control what you can do? Absolutely, emphatically yes.

 

[Mylton]

I did exactly that for one of my bigger projects for the U.S. Navy, in that only a person who had the "system administrator" role could see the CREATE button (to create a new button for a project.) Only a project manager could use the CREATE button (to create a new project to which resources could be added)... and so on. In each case, the Form_Open event determined the user and verified roles & privileges. The Form_Load event had access to and could therefore hide or reveal particular buttons. For cases where someone was updating a server, the Form_Current event could see whether the user was allowed to touch the particular server and modified the AllowEdit (and related properties) as required. So do I think it is valid to use VBA to control what you can do? Absolutely, emphatically yes.

Show
Thanks

 

[Mylton]

I'm sorry show for us is not equal to show.
would be something equivalent wow, thanks

 

[Pat Hartman]

1. the idea
would prevent copies and use after evaluation time.

Should you be attempting to create an application you intend to sell using a platform you don't understand?

2. to control who does what in the app.

That is exactly what the switchboard with login is intended to do

3. Your switchboard example is trying to integrate a login and open a menu according to the employee's department. I would say that I am advancing at a slow pace.

What part of that do you not understand? "department" is an arbitrary choice based on years of development experience. The department here you work is the primary discriminator for what you can do. As I said in one of my explanations. Call "department" something else if that makes more sense to you. You need to be able to do at least a little thinking outside the box when reviewing examples.

4. I already thought of using a BE in sql but this should also be installed on the person's machine and as my idea is for use in small offices with 1 secretary and 1 or 2 medical colleagues, I don't know if there is any way to do the installation and sql configuration automatically.

Unless the company has IT to support a SQL Server install, then SQL Server is not a good fit. For the apps I sell, the client has the option of using ACE (Access) or SQL Server as the BE. The small operations choose ACE.

 

[Mylton]

Should you be attempting to create an application you intend to sell using a platform you don't understand?

That is exactly what the switchboard with login is intended to do

What part of that do you not understand? "department" is an arbitrary choice based on years of development experience. The department here you work is the primary discriminator for what you can do. As I said in one of my explanations. Call "department" something else if that makes more sense to you. You need to be able to do at least a little thinking outside the box when reviewing examples.

Unless the company has IT to support a SQL Server install, then SQL Server is not a good fit. For the apps I sell, the client has the option of using ACE (Access) or SQL Server as the BE. The small operations choose ACE.

Good Morning.

it's not about selling. it's about protecting a model of thinking that they haven't done the way I'm thinking.

as for the other tips... i'll think outside the box.
thanks for the teachings