Question Access Back End. Can I use a random file extension?

[BiigJiim]

Hi,

I am developing an Access database with a Front End and two Back End files where is it absolutely essential that users of the computer cannot access one of the Back End data files in any way or even make copies of the file itself. The other Back End file isn't a problem.

I have done all the usual procedures: password protect the database, disabled the AllowByPass, and included our own user-security which runs when the file is opened.

However the only way I can think of to prevent the file being copied is to hide it in an obscure system folder and give it an obscure name and file extension. eg abc123.xyz. No one will know where this file is. There will be no linked tables from the front end, which will open connections to the database in vba when it needs to access the data tables.

I have tested and it seems to work. Is there any reason why I should not do this and is there a better way?

Thanks as always!
Jim

 

[MarkK]

I don't see why this wouldn't work. If you would be kind enough to try it and report back so we can all benefit from your experiment, that would be very much appreciated.
Thanks in advance,

 

[MarkK]

Sorry, I didn't read your post closely enough, so you tried it and it works.

I think this is a good strategy. To me the best security is that no one knows the valuable thing even exists, and failing that, if they know it exists but can't find it.

 

[The_Doc_Man]

You are attempting what is called "Security by Obscurity" and you are merely throwing barriers before your users. But barriers can be side-stepped by a persistent person with a hacker mentality.

There are ways for persistent folks to decipher what you are doing if they want it badly enough. The code that establishes the dynamic BE file connection is in the FE. You CANNOT hide it completely.

Obscure folders and obscure file names might work for now, but in the long run, they are just speed bumps. Putting them in a system directory might work, but the security requirements for such folders can be somewhat of a problem. Windows doesn't like folks dinking around in system folders. Some other obscure location might be better but offer less difficulty in managing the security.

What you REALLY need to do is consider is a risk/reward analysis and a backup regimen to protect that 2nd file. You have to ask yourself:

What is the risk (monetary value) if this file is copied?

What is the cost (monetary value) of adding complex security measures?

How often do you expect someone to copy the file?

Do you anticipate internal or external threats? External threats can be managed with a darned good firewall. Internal threats are harder to manage. Sometimes using a formal non-disclosure agreement (with lawsuit or other monetary penalities) can deter the casual internal hacker types. Sometimes you just can't stop a determined hacker.

In the end analysis, the question is: How much are you willing to do? And think about this - if your business crumbles to ruins when someone copies that file, have you already designed too many eggs in one basket? Is your own design your biggest enemy?

Before you ask: I was a systems administrator with the U.S. Dept of Defense for 28 1/2 years before I retired. I had security certifications for commercial providers and several certificates for operational security, document classification, and records management. So I'm not accusing you of bad design. But I am telling the questions you need to ask to decide that for yourself.

 

[Galaxiom]

I am developing an Access database with a Front End and two Back End files where is it absolutely essential that users of the computer cannot access one of the Back End data files in any way or even make copies of the file itself.

Then don't use Access as the back end because there can be no absolute protection with a file based back end. It needs to be hosted via a database server.

 

[BiigJiim]

You are attempting what is called "Security by Obscurity" and you are merely throwing barriers before your users. But barriers can be side-stepped by a persistent person with a hacker mentality.

There are ways for persistent folks to decipher what you are doing if they want it badly enough. The code that establishes the dynamic BE file connection is in the FE. You CANNOT hide it completely.

Obscure folders and obscure file names might work for now, but in the long run, they are just speed bumps. Putting them in a system directory might work, but the security requirements for such folders can be somewhat of a problem. Windows doesn't like folks dinking around in system folders. Some other obscure location might be better but offer less difficulty in managing the security.

What you REALLY need to do is consider is a risk/reward analysis and a backup regimen to protect that 2nd file. You have to ask yourself:

What is the risk (monetary value) if this file is copied?

What is the cost (monetary value) of adding complex security measures?

How often do you expect someone to copy the file?

Do you anticipate internal or external threats? External threats can be managed with a darned good firewall. Internal threats are harder to manage. Sometimes using a formal non-disclosure agreement (with lawsuit or other monetary penalities) can deter the casual internal hacker types. Sometimes you just can't stop a determined hacker.

In the end analysis, the question is: How much are you willing to do? And think about this - if your business crumbles to ruins when someone copies that file, have you already designed too many eggs in one basket? Is your own design your biggest enemy?

Before you ask: I was a systems administrator with the U.S. Dept of Defense for 28 1/2 years before I retired. I had security certifications for commercial providers and several certificates for operational security, document classification, and records management. So I'm not accusing you of bad design. But I am telling the questions you need to ask to decide that for yourself.

I agree, all legitimate questions. At the end of the day this is about the wishes of my client, not for my own system. Unfortunately it is not possible to host the database on a server - it is on a laptop.

The access vba code will be compiled into accde format. Am I right in saying that it is extremely difficult, if not impossible, to extract the vba code from an accde or mde file?

This doesn't have to stand up to Russian government sponsored hackers, just semi-experienced IT users who may have access to both the laptop and the front end program for a considerable time. So effectively internal threat rather than external.

 

[Galaxiom]

Unfortunately it is not possible to host the database on a server - it is on a laptop.

The laptop can still run a database server. The data files can be assigned Windows permissions to prevent direct access by the users. The server logins can be configured only allowed authorised users to directly see the tables but allow ordinary the required permissions to query the database.

The access vba code will be compiled into accde format, so it should not be possible to extract the name and location of the file from the code?

Strings remain visible as plain text in compiled code. Finding the path and password of the back end would be trivial unless you include code to encrypt them.

This doesn't have to stand up to Russian government sponsored hackers, just semi-experienced IT users who may have access to both the laptop and the front end program for a considerable time. So effectively internal threat rather than external.

A few minutes would be more than enough where they have physical access to the computer.

 

[The_Doc_Man]

You owe it to your customer/employer to advise that there are risks to be had. The most important question to ask is the one about whether the business goes belly up if the file gets copied.

Galaxiom's comments about running some type of SQL engine (other than Access Jet or Ace) are appropriate. Consider this: If you have to run SQL Server or something like it on the CPU, at least your network delays will be miniscule because you would be connecting to the server through the Loopback port. NO net exposure, no delays because of going through a modem.

Hacking tools exist that would search for text strings in the midst of binary soup. What is worse is that you have said someone might actually be in possession of the hosting laptop. There are ways to allow persons to see all sorts of Windows internal structures if they know how to look.

Access is designed for a SMALL business that might grow into a "big boy" back end engine - but has not done so yet. It has many important features. Tight security is not one of them.

 

[Galaxiom]

You owe it to your customer/employer to advise that there are risks to be had.

Indeed. I would want a signed acknowledgment stating they understood and accept the specifically noted risks. Otherwise you leave yourself open to liability.

It is a general principal that allowing any physical access to a device negates all security measures implemented on it.

 

[BiigJiim]

Thanks for everyone's input.

Ok, we are looking at doing this another slightly different way. Some trusted users in the office need access to the confidential data and will know of it's existance, other's do not need it and (hopefully) should not become aware of it's existance.

One option therefore is to have 2 versions of the Front End, and 2 back end files, one containing all the everyday data everyone needs access to, and the other containing the confidential data. Because the database is now going to be multi-user, the back end files will reside on a server. One front end will be for all everyday functions, and will not touch the 'secret' back end at all, the other will have the additional functionality. Non-trusted users will NOT have any access to the enhanced front end and will hopefully not even know it exists.

Because the data is now going to be stored on a server, which all users have access to, it is still proposed to put the secret data in an Access file (sorry, it has to be Access) with a random name and extension, in an obscure folder.

Would there be any easy way for a user to locate the abc123.xyz file if they do not know what they are looking for, their FE file contains no reference to it and they DO NOT have access to the modified FE?

I suppose also the other part of the question is: does changing the back end file extension have any impact on Access's ability to interact with the file?

 

[The_Doc_Man]

IF you use the concept of a switchboard that totally hides all Navigation Pane items from your users, then you could have a "miscellaneous" table in the BE that, since no one sees it, will effectively be invisible. You can put a text string as a field in this table and store the file link that way. The text string would then never occur in cleartext anywhere in the static FE file. It would only appear in a memory-resident string in the FE task memory while it is in use, and that would be much harder to detect. (But... memory sniffers DO exist.)

All you can ever do to prevent people from seeing the critical BE file is to get Windows to help you. This isn't bullet-proof either, but consider this approach. Have your IT guys help you if you can't do this (and if you have IT guys, they probably have blocked you from doing it anyway...)

Make two domain-based groups representing two classes of user. Call them anything you want. Fred and George for all I care.

Give the GROUPS permissions to access the BE files. (More specifically, put GROUP ACLs on the two folders.) But... the privileged GROUP can see both BE files (ACLs on both folders); the non-privileged group can only see the non-critical BE (ACL only on one folder.)

Both groups still need Windows MODIFY level access on the folders and the files within those folders. If the folder path is a bit deeper on the machine, the folders above the critical folders just need the PASSTHRU permission. It would be up to the IT guys as to site preferences, but some places allow PASSTHRU to group "Authenticated Users." Others require it to be more specific. That is a question for your IT group.

Now add each user to the appropriate group. Do not grant permissions to individual users. If you have to add or remove user access, the FAST method is to add them or remove them in the GROUP membership.

This next part tells you how to dynamically tailor your FE so you won't NEED two different FEs. Easier and less confusing that way.

Since your connection to the critical BE is dynamic, something you could do in the FE is to have a VBA function you could call to test whether you can create a file in the folder in question (since you need that special GROUP membership to have permission to the folder.) Dink around with the File System Object a bit to see if you can do something useful there. (If you actually create a test file, remember to KILL it when done.) And the key is that the folder, which is NOT a system folder but IS specially created, would normally NOT grant WRITE permission (or DELETE permission) to just anybody. So if you can create a file in the special folder, you know that you are in the special group. That way, you can decide very early in the process whether you are going to need to use that dynamically linked BE.

There are many ways to skin this cat, but you can do some command tailoring in each relevant form's Form_Load routine to test whether you have that level of access and if you DON'T, make the relevant controls (text boxes, combos, lists, command buttons, whatever) become INVISIBLE. (ctrl.Visible=False for most of those.) But if you have a form that you never want opened in the first place, make its launch button invisible on the switchboard form. AND you can put code in the form's Form_Open routine to do that test and return a Cancel if the test fails. You can cancel an Open but not a Load, so if you are going to hide the form totally, remember it has to be in the Open. But if it is merely some controls, it could be in the Load event.

As to odd file names? If you can link to the name using Linked Table Manager then that is the acid test. If it works, it works.

 

[CJ_London]

does changing the back end file extension have any impact on Access's ability to interact with the file?

I use a different extension instead of .accdb/.accde, not so much for obscurity but so I can associate my logo with the extension.

I have had no problems or performance issues with using a different extension.

but do encode your text for filepath/password etc as Galaxiom recommends

Strings remain visible as plain text in compiled code. Finding the path and password of the back end would be trivial unless you include code to encrypt them.

Other thing you can do is hide the backend - but again easy for someone to show hidden files

 

[Galaxiom]

Would there be any easy way for a user to locate the abc123.xyz file if they do not know what they are looking for, their FE file contains no reference to it and they DO NOT have access to the modified FE?

The first few characters of an Access file are always the same (slightly different between mdb and accdb). A simple script could recurse through the folder structure and look for those characters at the beginning of the files.

Security through obscurity is no security.

 

[BiigJiim]

The first few characters of an Access file are always the same (slightly different between mdb and accdb). A simple script could recurse through the folder structure and look for those characters at the beginning of the files.

Security through obscurity is no security.

That's useful to know, thanks Galaxiom.

 

[BiigJiim]

I use a different extension instead of .accdb/.accde, not so much for obscurity but so I can associate my logo with the extension.

I have had no problems or performance issues with using a different extension.

but do encode your text for filepath/password etc as Galaxiom recommends



Other thing you can do is hide the backend - but again easy for someone to show hidden files

Thanks CJ. Good to know that it won't cause performance or reliability issues. I'd never thought about the logo idea I just set the logo in the Database properties.

 

[CJ_London]

I just set the logo in the Database properties.

that works within Access, but you will have the access icon in the taskbar and on shortcuts, file names etc.

 

[kevlray]

The best way that we can hide data beyond just FE and BE is to have the BE on a database with more robust security (i.e., MS-SQL) and the users that need not have access to particular tables will not have those rights on the database.