Solved Disable the setting of AllowBypassKey property from another db (1 Viewer)

[bob fitz]

Does anyone know of a way to prevent the setting of the AllowBypassKey property being changed by another db

 

[arnelgp]

it is a database property, so directly to the database, no you can't prevent others.
but if you use a 3rd Tier accde db (without table), it can be cracked but will
give it a hard time to figure out where the data is coming.

 

[isladogs]

No - any database property can be modified externally.
Suggest using a combination of measures to make it more difficult for others to break your security.
For example, see

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

 

[bob fitz]

....but if you use a 3rd Tier accde db (without table......

Can you tell me more about this. I know what an accde file is but what is a "3rd Tier accde db"
Thanks for your interest.

 

[arnelgp]

forget about 3rd tier, you can do it on the FE.
instead of Binding your Form/Report to a Table or Query,
use the Load/Open event of your Form/Report to set the recordsource/recordset.
so no table/query exists on your db.

of course this is hard coded, so the path to your BE
must also be fix.

 

[bob fitz]

No - any database property can be modified externally.
Suggest using a combination of measures to make it more difficult for others to break your security.
For example, see

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

Hi Colin. Thanks for your interest.
It was looking at that link that prompted me to ask the question that I asked.
Perhaps I've missed something there but it seemed to me that once the AllowByPass property is changed back it allows someone to undo most of the other things?

 

[strive4peace]

hi @bob fitz

while you can't prevent someone else from changing AllowSpecialKeys from another database, you CAN redefine what F11 does with an AutoKeys macro (that you could mark to be Hidden). This is example just shows a message box. Instead, it could set itself back, along with other properties like StartUpShowDBWindow, and exit the database! Maybe even trigger running a batch file after the database is closed with some scary message.

 

[isladogs]

Hi Colin. Thanks for your interest.
It was looking at that link that prompted me to ask the question that I asked.
Perhaps I've missed something there but it seemed to me that once the AllowByPass property is changed back it allows someone to undo most of the other things?

Yes that is indeed true.
The third part of that article contained a list of proposed additional security measures which I sent to MS & which would help to plug some of the weaknesses in Access security. See:

Additional Security in Access Databases

This is a list of suggested changes that could help make Access databases much more secure

www.isladogs.co.uk

However, if you use a number of different security measures, they will need to identify each of those and then overcome them if they know how.

What @arnelgp was referring to, is the use of disconnected ADO recordsets.
I have an example of that approach you can look at & try to 'crack' if you wish:

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

In the end, how much security is worth using will largely depend on who you are trying to protect your databases from

 

[isladogs]

while you can't prevent someone else from changing AllowSpecialKeys from another database, you CAN redefine what F11 does with an AutoKeys macro (that you could mark to be Hidden).

Just to clarify, disabling special keys such as F11, has absolutely no effect on the shift bypass. That has to be disabled separately.

 

[strive4peace]

yes that's true ... just that the Autokeys macro DOES run even if the database is opened with Shift ... so it could contain other definitions as well

 

[isladogs]

yes that's true ... just that the Autokeys macro DOES run even if the database is opened with Shift ... so it could contain other definitions as well

Yes of course any code will run after the database has been opened using the shift bypass.
All that does is prevent code running at startup

 

[bob fitz]

My thanks to everyone that has contributed here.