Solved Accede file (1 Viewer)

[zelarra821]

Good morning.

I want to somehow protect the databases I make for the people who ask me for them.

I had programmed for several years a form that I have called Configuration, so that the user could customize his application.

In the last update I've made to this form, I've added two security buttons:

- One to access the Administration Panel, protected by a password that only I know. It is a FormUser where the code of the hard disk manufacturer and a username are added to a Users table. It also allows you to delete users. This code is reviewed when entering the database, and if it does not exist, a MsgBox of information to the user and access to the Administration Panel, protected, jumps.

- And one last button to enable the Shift key, also protected by a password that only I know.

The next step I would like to take is to protect the Visual Basic code.

As I have read, setting a password to the VBA project is easily removable. The one I have found most feasible is to generate an .accde file.

Therefore, I ask you my doubts about using an .accde file:

1. Can it be unprotected somehow?

2. Can you export the objects (tables, queries, forms and modules) from that type of file?

3. To update the database, I previously deleted all queries, forms, macros, modules, and class modules from the user's file, and imported them from the original file I had that I had updated. With the .accde file, you would have to import the tables and queries. Are there any drawbacks that you are missing that are important?

4. Are these three layers of security enough?

I assume that I will always have the original version and the user accesses the .accde file.

I hope your answer.

All the best.

 

[isladogs]

Questions 1-3
Please read my article on this topic and check out my example database

Improve Access Security 2

This article explains how to apply various security measures to make your databases as secure as possible. An example app is used to illustrate the possible methods available

www.isladogs.co.uk

Question 4
Only you can decide how much security is 'enough'. It is physically impossible to secure any application completely. Access itself is certainly not 100% secure no matter what you do.

As for your updates, your application should be split. If the configuration settings are in the frontend, then you could use my approach of having a configuration database as a separate 'side-end' database.
Then supply the update with no data. When the user first runs the update, the backend tables are relinked and the config data is recovered from the 'side-end'.

 

[zelarra821]

Hello. Your guide is great. Many of the things you propose I have done in my databases.

It is clear to me that there is no 100% security. Thank you so much.

Now, I would like you to point out two things:

1. If the database is only going to be used by one person, should I still split it up?

2. The configuration form is based on a table where its values are stored. These settings are not relevant to security (application name, favicon, file folder path, enable backups and format the database). Yes it is true that in this table I store in a Yes/No field if the Shift button should be activated or not. I don't know of any other method to save it other than in a table. So is this okay? I don't quite understand the "side-end" concept, if you could explain it a bit better.

As I said before, thank you very much.

 

[ebs17]

If the database is only going to be used by one person, should I still split it up?

I would say always.
A good application will inspire the user and create desires for more functionality. So it will never be "finished", but will potentially be developed further in time steps.
For further development, it is easier to revise the frontend and then replace it at the user.

It may also be that the user has collected data that is none of your business for privacy reasons. So the backend remains with the user. For the further development of the application, you only need a structurally identical backend with some meaningful game data.

I don't quite understand the "side-end" concept

You can include more than one backend in a frontend. So while the backend with the master data could be located somewhere in the network to enable multi-user operation, such information about individual settings in a local backend is located directly at the frontend.

So if the frontend is replaced due to further development, the individual settings data is retained.

 

[zelarra821]

And the last question. How necessary or useful is it to pass the frontend to accde?

 

[ebs17]

In an ACCDE, the VBA editor and the drafts of forms and reports are locked and thus not accessible by the user.
Tables, queries and macros are not protected, whereby macros should rather occur less in usual applications.

Anything that helps prevent the user from accessing and playing with definitions and programming is useful. So yes, generally ACCDE. Actually, the frontend should also run under runtime conditions (=> ACCDR), so that a user doesn't necessarily have to get an Access license.

However, such safeguards require clean and error-free programming and good implemented error handling.

 

[zelarra821]

Let's see, I have two questions:

1. Is it possible to store data without it being stored in a table?

2. What do you mean by this?

Actually, the frontend should also run under runtime conditions (=> ACCDR), so that a user doesn't necessarily have to get an Access license.

I think I understand that this format could be executed with a program other than Access. I'm right?

 

[isladogs]

Post #3
1. Yes - it makes supplying updates significantly easier as already stated by @ebs17
2. A 'side-end' database is commonly used to store settings related to the front end for easy retrieval
The same phrase is often used to indicate a separate database used to store 'temp' tables in order to reduce database bloat in the FE

Post #7
1. Yes - in database properties or variables or tempvars
2. A runtime version of Access is available free as a download. It can be used by users who do not have a current license for Access. It is also useful as all databases are highly locked down - this is discussed in my article linked in post #2.
However, remember that users can rename an ACCDR file as e.g. ACCDE which undoes some of the 'security'

For info, you do NOT need to store information about the shift bypass state as it is a Boolean database property
One way of coding when the shift bypass should be disabled is when the user name & computer name match specified values. You can take it even further and, for example, check whether the CPU ID & motherboard ID match that on your computer.
Whether all of that is worth the effort is another matter.
For info, anyone who knows how can easily disable the shift bypass from an external database.

Only you can decide what is really worth doing in terms of security.
What are you trying to protect against? Data being stolen? Your code being stolen?
Who are you trying to protect against? User tampering? Professional hackers?

 

[zelarra821]

1. Yes - in database properties or variables or tempvars

But these are lost when you close the database, right? At least with the TempVars. I don't know how to use the rest of the options (variables or properties) that you have mentioned.

2. A runtime version of Access is available free as a download. It can be used by users who do not have a current license for Access. It is also useful as all databases are highly locked down - this is discussed in my article linked in post #2.
However, remember that users can rename an ACCDR file as e.g. ACCDE which undoes some of the 'security'

Regarding this, two questions.

1. Can I use the runtime version of Access on Mac?

2. You will say that the user can switch from accdr to accdb and lose some of the security. But what part of security? It will only be the one referring to the protection of VBA, right? Or can it affect more things?

What are you trying to protect against? Data being stolen? Your code being stolen?
Who are you trying to protect against? User tampering? Professional hackers?

What I'm looking for is that anyone I create a database for can take advantage of my time and effort. I have read in another forum that a true professional does not hack a program, but does it again.

 

[ebs17]

store data

The counter question would be: What data for what and with what lifetime?
Saving in the true sense means that the information is retained even after the application is closed.

 

[isladogs]

Properties are stored as part of the database. That's why they are available each time it is opened

You do like your 'two questions'....
1. No
2. Please study my series of articles more closely as almost everything you've asked in included in the articles and/or example database

 

[Josef P.]

[hack a program]
You usually cannot change a compiled accde back to an accdb. (Unless your name is Wayne. )
This protects the code from modification.
The accdr extension only triggers the "Runtime" mode. (It does not matter whether this is an accdb or an accde.)

The data structure in an Access file is more difficult to protect.

 

[zelarra821]

Everything is more or less clear to me. Thank you very much guys for the information.

 

[isladogs]

[hack a program]
You usually cannot change a compiled accde back to an accdb. (Unless your name is Wayne. )

You're being deliberately obscure there Josef!
For the benefit of the OP, there is a company called EverythingAccess led by a brilliant developer called Wayne Phillips.
They can reverse engineer ACCDEs back to ACCDB but
a) as they are a reputable company, will only do so if proof of ownership can be provided
b) they are certainly not cheap

I am significantly less brillant than Wayne but I can still extract a lot of information from ACCDE files (without reverse engineering them)