Most Secure way to re-enable shitf bypass key (1 Viewer)

[Cowboy_BeBa]

Hi all

So im working on a new version of my DB and wanna make sure its secure AF. I usually disable the bypass key and set it to be reenabled once i put in my username and password (specifically me, if any other users use their login details it wont work)
In the past ive also added secret buttons, ie a picture that acts as a button (though it would be disabled unless im logged in) clicking it would prompt a user for a code which would then enable the bypass key
or just used a certain password that, when entered enables it

This time round though, im thinking of something a lil different
was considering placing a text file with a given name (ie. bypass.txt) onto the C drive, when the db opens it checks for the existence of that file, if it exists it will read that file, if the contents of that file match a string i create (just completely random characters) then the bypass key will be enabled, otherwise it would be disabled

just wondering if anyone else has any other ways of going about it that i may not have thought of?

Also, i once read somewhere it was possible to create a new database and write some VB that will select the other database and enable its bypass key
is this a thing? if so how would i go about doing it and (more importantly) is there any way to prevent this from happening?

 

[CJ_London]

Also, i once read somewhere it was possible to create a new database and write some VB that will select the other database and enable its bypass key
is this a thing? if so how would i go about doing it

yes. in vba in another db, create another access application, open the file and change the property. Code will be pretty much the same as what you are using at the moment.

and (more importantly) is there any way to prevent this from happening?

Not really. You could password protect the db, but then chances are whoever is wanting to do it will know the password.

If you are worried about security, you need to decide what you are protecting (data? code?), who from (someone visiting, a regular user, an occasional user, etc) and from what (theft, malicious intent, bumbling attempts to change things/find shortcuts, etc).

Whatever you do, given enough time and resources, it can be broken into.

With regards your idea of a text file, I don't see how that would work since you need the code to run to check the file - and if someone has disabled the bypass key, the code won't be running

 

[The_Doc_Man]

It is indeed possible to do some things from another DB that opens yours manually and tweaks the settings that control security features. Or the miscreant person who is about to do you in could just copy everything to a new blank database. POOF, there goes a raft of security measures.

There is no absolute way to stop this, either. You can make it harder but not impossible. Making a compiled version (.MDE/.ACCDE) for distribution will at least make it harder to navigate from another copy of Access. The cost is that you have to maintain a "Design Master" for the purpose of maintaining your published, compiled copy of the app.

Putting an encryption password on a database makes it harder to diddle, but if a user (who by definition of the method, must already have the password) decides to diddle you, that will be impossible to completely block.

The whole issue in simplest terms is that Access is not designed for a high-security database. It is a small-business tool. Dept. of Commerce studies show that 80% of all businesses in the USA qualify as SMALL businesses, so OF COURSE Access is targeted to the biggest market share, not the most stringent one.