Create ACCESS 2013 from ACCDB to ACCDE

[johnseito]

If I can create exe that only contains code that can’t be break into that would be good.



If people can access it, delete tables what is the difference between ACCDB vs ACCDE ?

[CJ_London]

what is the difference between ACCDB vs ACCDE

in .accde a user can't change the code or modify forms, reports and modules. Designing something that doesn't use tables or queries will be about as close to a .exe as you will get - but then it wouldn't be a 'database'. However be aware that compiled code can still be read by those who know how to - there are sites out there who claim to be able to convert back to readable code. Certainly hard coded values (such as a password) can be relatively easy to identify. So to be more secure you need to make your readable code more obscure.

As I said in my previous post you need to clarify what you are protecting (data? design? something else?), from whom (anybody, low skill level, high skill level, accident) and why, then design the appropriate security strategy and implement. A JET/ACE rdbms (which is what Access provides free with the application) is not particularly secure - you can just copy it to a thumb drive for example.

[johnseito]

I could of lock the codes and not create the ACCDE. Almost the same.

[isladogs]

A capable and determined hacker will always be able to crack an Access app given enough time and the motivation to do so.
In fact that is true of most software and indeed buildings.

What you can do is put up a series of hurdles that will be enough to deter most users from cracking your database security.
First decide which is most important: Data or Code ...or both.

As Ajax has said, if you want to prevent anyone stealing your code, use an ACCDE.
You can also use a strong password to protect the app so only authorised users can open it.

To prevent anyone opening your tables directly, you can do a number of things including...
1. Hide the navigation pane, ribbon and if you want, the entire application window
2. Block the shift bypass
3. Split the database and put your data into SQL Server which is more secure
4. Make your tables deep hidden so these cannot be viewed from the navigation pane or even from external databases.
However, even then there is a work round...if you know how!
5. Encrypt your data using a strong encryption cipher

Combine all that lot, and you will deter almost all hacking.
There are other techniques also....which I'm deliberately not mentioning here.

You might want to look at my two security challenge examples which illustrate various methods of making apps reasonably secure.
See https://www.access-programmers.co.uk...d.php?t=300806 and https://www.access-programmers.co.uk...d.php?t=300434.
Both are designed to be solvable and hopefully 'fun' to do

The first one is relatively easy to do.
The second has only been completely solved by one person so far out of 150+ downloads... despite some significant clues I provided.
He did so by hacking every part of the security step by step. It took him hours.
In fact it can be done more simply without hacking and, using the correct approach, in just a few minutes.

I'm also working intermittently on challenge #3 which uses additional techniques....

[johnseito]

Thanks for the info.
I want to hide and lock with no view or access to the tables, queries (system and unsystem related) and the codes. By our discussion and your examples it looks like it’s not possible ?

Could you show how to do this if it could be done ?

[CJ_London]

there are plenty of threads on this subject - just google it

[johnseito]

I locked and code to hide with Autoexe bu I don’t think that is enough. Thanks for the info though

[isladogs]

Thanks for the info.
I want to hide and lock with no view or access to the tables, queries (system and unsystem related) and the codes. By our discussion and your examples it looks like it’s not possible ?
Could you show how to do this if it could be done ?

Ajax & I have already told you how to do most of these things: hide navigation pane, hide ribbon, hide application window, disable shift bypass, distribute as ACCDE, encrypt with a password, store data in a SQL Server BE etc.

You can easily find how to do each of those online.
My example database: https://www.accessforums.net/showthread.php?t=69856 shows how to hide each of those items

If you did look at my security challenges, these include the above features (and more)

They also include deep hidden tables which cannot be viewed from the nav pane even if hidden objects & system objects are made visible.
It is MUCH more difficult to find out how to create these online & even harder to find out how to make them visible again.

I know how to do both BUT I'm not going to explain how.
If I did so, their use for security would be completely ruined by making their properties common knowledge.

When you say you want to lock tables do you mean make them read only? That can also be done

Attached is a simple example database with 2 deep hidden tables & 1 form.
The form has a button which will toggle the visible state of one of these tables. It is READ ONLY.
It is an ACCDE file so the code is not available for viewing
However its deliberately not fully locked down in this case

There is another deep hidden table - see if you can work out its name & contents
If you succeed, please send me a PM - do NOT post the solution here

NOTE: I don't know of any way of making queries deep hidden

[CJ_London]

I don't know of any way of making queries deep hidden

only way I know is by putting the sql in a deep hidden table and using code to create the recordsource/rowsource whatever as required or creating temporary queries. Small overhead in building the execution plan but at least they are hidden!

[isladogs]

As we are talking about ACCDE files, doing 'queries' in VBA means they are automatically hidden.
For action 'queries' you would just need to execute a SQL statement in VBA
Your suggestion might be worth exploring for a select query though.

Or of course you could do all 'queries' in SQL Server as views.
Link the views as well as the SQL tables.
As Access treats them both as linked tables, just deep hide all of them (not tested)

[johnseito]

I am looking into your info and thanks for the valuable info on how to do most of the security features.

How do we disable shift by pass. I never seen it done and never done it.

[isladogs]

Google search is your friend. Some links:
http://www.databasedev.co.uk/disable_shift_bypass.html
https://support.microsoft.com/en-gb/...ss-database-pr (ignore the ADP part)
https://www.access-programmers.co.uk...ad.php?t=51479

Or look at the code in my kiosk style example: https://www.access-programmers.co.uk...d.php?t=300831

NOTE: Make sure you don't lock yourself out as well!

[CJ_London]

doing 'queries' in VBA means they are automatically hidden

but reduces flexibility for maintenance and updates.

[isladogs]

but reduces flexibility for maintenance and updates.

True but then I update using an ACCDB file anyway....

I've just tested a linked SQL Server table & a view.
As I expected, both can be deep hidden & restored as for local tables.
It also works for other linked items: CSV files & XLSX files both tested.
So I expect anything that can be linked as a table would work

I've also just worked out how to make read only system tables using VBA by changing their properties.
It can of course also be done using the USys prefix but those are still editable.

[johnseito]

I see how you can disable the shift key so can’t go into tables and queries but how do you enable it for developers ?