Prevent Importing Odbc Tables From ACCDE (1 Viewer)

Hello guys
There is a problem in my access application and i hope you guys can help me

I use sql server backend and everything is great and i dont have any problems but when i tried to distribute my workstations i tried to import the tables in the accde to a new accdb file and the shock was that the tables got imported
The more shocking thing was i extracted the connection string using tabledef.connecti am sure i am not the first programer to encounter this problem

Is there any fix for this issue cause the only thing i can do is using dao recordsets and delete the tables and this will require that i rebuild my forms so it uses dao instead of linked odbc tables

Please guys help me solving this security issue

Hi. I saw your other thread and was wondering how sensitive is your data.

This exact same question has been posted on UA. - So I quote my exact answer from over there.

hima193 said:

Please guys help me solving this security issue

Click to expand...

My answer from UA:

What exactly is the issue?

I see this question over and over again, and my opinion is opposed to what many other developers think.
The the hyper-condensed summary: If your backend database is secure, there is no issue at all.

You can read an extensive text on the issues involved, some solutions proposed and the reasoning behind my opinion the the article Authentication Mechanisms for Access + SQL-Server-Applications.

Click to expand...

Thanks my friend i replyed on UA

hima193, please be aware that we (and many other sites like this one) tend to frown on what we call cross-posting. That is, you ask the same question on multiple sites. The reason is that if we don't know you have an answer on another site, we waste our time in trying to answer you. In essence, we re-invent the wheel when that happens.

However, I also want to be clear that since you are new, we make allowances. Our usual preference is that you can cross-post IF YOU TELL US YOU DID! Post a link to the other site(s) where you asked the question. That way we can check whether you have an answer or are still waiting. Cross-posting without revealing that fact is kind of like a slap in the face to those who work as volunteers to offer help to people like you.

I want this to be taken as a relatively GENTLE reminder that we have a preferred etiquette to cross-posting. If you comply with that etiquette, no problems!

Ok my friend i didnt know that
And btw i figured a difrent aproach which is removing linked tables and use dao instead to populate the recordset of the form

I use a similar approach in this demo though for an Access BE
https://www.access-programmers.co.uk/forums/showpost.php?p=1612513&postcount=7

However, whilst you can do this, its not clear why you think you need to do this. If someone is able to access the FE legitimately (or by hacking), they will have access to your forms and therefore your data. They will still be able to extract your table data. You can make it hard for them to do so with lots of additional security but you can't prevent a determined and capable person doing so.
If your data is that sensitive, I would question whether an Access FE is the correct approach

isladogs said:

If your data is that sensitive, I would question whether an Access FE is the correct approach

Click to expand...

Any reason why you imply Access is a less secure frontend than frontends built with other technologies?
Or are you rather referring to the 2-tier client-server architecture vs. a 3- or multi-tier architecture?

Hi Phillip
This answer is partly in response to you but also to the OP

As Access is a file based application, it is inherently less secure than a server based application like SQL Server.
I've read your article about security in SQL Server and found it very informative.

I believe you are aware that I have written several articles about security issues with Access and indeed about ways of making it as secure as possible.
My security challenges have been intended as 'fun' ways to test security and by attempting these the idea is to encourage others to think about & build in additional security in their own apps. All of the challenges contained deliberate weaknesses to allow them to be solved. It is also true that each also included unintentional loopholes, some of which (not all) were found by those who tried the challenges.

I've been working intermittently over the past 6 months on a further challenge which coincidentally uses this approach with an Access BE to avoid using linked tables. My intention this time is to make it as secure as is possible with Access. However, each time I think I've achieved that, I discover another unexpected 'way in'.

As I've written elsewhere:

Access databases can NEVER be made 100% secure
A capable and determined hacker can break any Access database given sufficient time and motivation
However, by erecting various barriers, it is certainly possible to make the process so difficult and time consuming that it isn't normally worth attempting

Click to expand...

Using a record source created on opening forms in an ACCDE (and destroyed on closing) is certainly an additional security measure.
It will definitely slow down anyone trying to steal data. However, any app is as secure as its weakest entry point.
Unless the OP is certain that EVERY back door has been closed, the data will still be accessible with sufficient effort by a determined hacker

A capable and determined hacker can break any Access database given sufficient time and motivation. However, by erecting various barriers, it is certainly possible to make the process so difficult and time consuming that it isn't normally worth attempting

Click to expand...

From a different perspective, you can take out "Access database" from that statement and substitute some other computer-based application for practically ANY brand-name and product name. I worked with the U.S. Dept. of Defense for over 25 years before I retired. I was both a systems administrator and (for my assigned systems) the security first-line administrator. The U.S. Navy DRILLED it into our heads that you can NEVER be secure in any system that is functioning. We had ORACLE systems, SQL Server systems, and a smidge of other databases. We had PEOPLESoft systems, SAP, and a few other frameworks. We had a bunch of non-database apps that were essentially transaction flat-file movers. You name it, we had it, including stuff that was older than my oldest grandson. Whatever we had, the same kind of ideas applied.

It's sort of like the game of golf. It's a game that you can't really win as such. You can only do better then the other players. If there is any personal contest in golf, it is that the player tries to beat the course designer's built-in challenges. And therein lies the analogy. A non-professional golfer is sometimes called a hacker, and in this viewpoint, it is surprisingly apt.

We had a phrase that was in common use for this principle - "the hackers go for low-hanging fruit." They like to spend their time on easier targets and will only hit a complex target if there is some perception of higher value to make it worth the effort. They way to protect yourself is to ramp up the effort required for penetration in order to counterbalance that perception of value to be gained.

To emphasize and corroborate Colin's statement, there is only one absolutely safe system configuration - the one in which your computer is turned off and has no power coming into it (so that it can't turn itself on through the BIOS sensors). That is the ONE machine configuration that absolutely cannot be hacked.

But of course, such a machine is of limited used - unless you like big, bulky paperweights. Anything else you do is a matter of relative rather than absolute safety.

Thanks for all your help guys and my problem is finally solved by AlbertKallal

You can find the answer in his post here
https://www.utteraccess.com/forum/index.php?s=&showtopic=2052939&view=findpost&p=2713060

Glad you've found a solution - I've used Albert's approach myself in the past.

You may also be interested in the DEMO database I've just uploaded here:
https://www.access-programmers.co.uk/forums/showthread.php?t=304218

It was written partly in response to several questions about making data secure including your thread....

The demo shows how you can use encrypted data in backend tables with no connection strings as a way of making it very difficult for anyone to steal your data.

However as already stated, it is impossible to make any Access database 100% secure against a capable and determined hacker with sufficient time and determination.
That applies equally to Albert's approach

Thank isladogs alot i will test it when i go home and will tell you how it goes

Thanks alot my friend for your help

thanks allot my friend and will use your aproach for some of my tables


and you also gave me an idea to encrypt the connection string itself so it can be harder to get


thank very much for your time bro