Hello all, newby from Amsterdam here with an ACCDE security quest (1 Viewer)

[orny]

Hello All!
I have been programming in Access for over 20 years, have always found it an extremely useful tool. My "specialty" is using Access as a front end and using MySQL as a backend. This usually works quite well. I stumbled into this group because I have always been interested in the security aspects of Access, and have been toying with something new in the past days. I entered via the "Encrypted-Split-No-Strings-DB" - thread.

I have just done my first tests using Access in combination with PHP calls over SSL to a SSL encrypted MySQL backend and a non-encypted ACCDE front-end. Anyone interested in trying to crack it open and tell me how they did it? As far as I could tell, Wireshark seems to show that there is just a lot of garbled bytes over the internet line. I tried to copy a new autoexec macro into th ACCDE, pointing to a new form, allowing me to alter settings. But I could only inject the rogue autoexec macro, not the frmRogueForm I had planned.

Look forward to hearing from you!


Best regards,

Pep

 

[Jon]

Welcome to Access World! We're so happy to have you join us as a member of our community. As the most active Microsoft Access discussion forum on the internet, with posts dating back more than 20 years, we have a wealth of knowledge and experience to share with you.

We're a friendly and helpful community, so don't hesitate to ask any questions you have or share your own experiences with Access. We're here to support you and help you get the most out of this powerful database program.

To get started, we recommend reading the post linked below. It contains important information for all new users of the forum:

https://www.access-programmers.co.uk/forums/threads/new-member-read-me-first.223250/

We hope you have a great time participating in the discussion and learning from other Access enthusiasts. We look forward to having you around!

 

[isladogs]

Hi and welcome.
I am the author of the encrypted split no strings example. You can find a newer version on my website at

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.

www.isladogs.co.uk

You can also find detailed advice on security in Access in my article

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

Unfortunately I don't use MySQL and am therefore almost certainly unable to assist with your request in another thread for assistance testing the security measures you have put in place.

 

[orny]

Many thanks! Will have a look!

 

[MsAccessNL]

Hello Orny,

I am from Amsterdam to. Iam experimenting with php api requests to get data into Access. Your question is not really clear to me. You want to inject a form into an existing accde?
Daniel.

 

[NauticalGent]

Welcome aboard!

 

[theDBguy]

Hi. Welcome to AWF!

 

[orny]

Hello Orny,

I am from Amsterdam to. Iam experimenting with php api requests to get data into Access. Your question is not really clear to me. You want to inject a form into an existing accde?
Daniel.

Hi Daniel, my question is really: how safe can I make my ACCDE? And I've bene testing this by trying to break into it. What I meant with that comment about injecting a form is that I tried to break into my own ACCDE by injecting a rogue autoexec from another application. That is easy enough to do. Fortunately, it is NOT possible to inject a new rogue form into an ACCDE. Groet! Orny

 

[orny]

ps: I am also using PHP and a Json parser to populate controls in my demo--app.

 

[CJ_London]

Normally the app is split and what you are trying to protect from theft or manipulation is the data which will be in the back end

usual reason for protecting the front end is to prevent modification to forms, reports and code. Also to prevent someone from being able to discover the password to the back end or use the front end to gain access to the data. And perhaps licence management

what is left ‘out in the open’ is queries, which for me is the weak point. But easy to overcome by not placing them in the front end - keep in the back end either as a querydef or in a table, or hard coded in the front end vba.

so ‘how safe’ depends on what you want to protect, from whom, from doing what, by what means

 

[MsAccessNL]

Normally the app is split and what you are trying to protect from theft or manipulation is the data which will be in the back end

usual reason for protecting the front end is to prevent modification to forms, reports and code. Also to prevent someone from being able to discover the password to the back end or use the front end to gain access to the data. And perhaps licence management

what is left ‘out in the open’ is queries, which for me is the weak point. But easy to overcome by not placing them in the front end - keep in the back end either as a querydef or in a table, or hard coded in the front end vba.

so ‘how safe’ depends on what you want to protect, from whom, from doing what, by what means

It’s not hard to retrieve the backend password from the linked table connection string (as you probably know). I think that the accde hack is useless without access to the vba code and the possibility to change the forms/reports.

 

[CJ_London]

It’s not hard to retrieve the backend password from the linked table connection string (as you probably know).

totally agree - which is why I don't use linked tables when data security is a specified requirement. Not prepared to go into what I do instead

 

[isladogs]

Hi Daniel, my question is really: how safe can I make my ACCDE? And I've bene testing this by trying to break into it. What I meant with that comment about injecting a form is that I tried to break into my own ACCDE by injecting a rogue autoexec from another application. That is easy enough to do. Fortunately, it is NOT possible to inject a new rogue form into an ACCDE. Groet! Orny

The article in my second link in post #3 mentions how to prevent a rogue autoexec macro having any effect

 

[orny]

Normally the app is split and what you are trying to protect from theft or manipulation is the data which will be in the back end

usual reason for protecting the front end is to prevent modification to forms, reports and code. Also to prevent someone from being able to discover the password to the back end or use the front end to gain access to the data. And perhaps licence management

what is left ‘out in the open’ is queries, which for me is the weak point. But easy to overcome by not placing them in the front end - keep in the back end either as a querydef or in a table, or hard coded in the front end vba.

so ‘how safe’ depends on what you want to protect, from whom, from doing what, by what means

My back-end is MySQL and I send very small cryptic instructions over SSL, the backend does all the querying and sends JSON back to the front end, again of course over SSL. No saved queries, no local tables at all.

 

[orny]

The article in my second link in post #3 mentions how to prevent a rogue autoexec macro having any effect

Just read your method for making sure the autoexec is protected. Nice one!

 

[isladogs]

You’re welcome.

 

[cheekybuddha]

My back-end is MySQL and I send very small cryptic instructions over SSL, the backend does all the querying and sends JSON back to the front end, again of course over SSL. No saved queries, no local tables at all.

I'm not sure what the benefit of using Access is in this situation.

BTW, have you investigated MySQL Rest Service API

 

[sonic8]

BTW, have you investigated MySQL Rest Service API

The link points to the MySQL Router REST API, which is some sort of load balancer/ HA failover router.

 

[cheekybuddha]

The link points to the MySQL Router REST API, which is some sort of load balancer/ HA failover router.

Yup, it's part of MySQL Router, but will work with a single instance of MySQL as well as with a replicated setup

 

[sonic8]

Yup, it's part of MySQL Router, but will work with a single instance of MySQL as well as with a replicated setup

It's probably just me...
I can't see (yet) how this would be of any use in the context of this thread.