Shift Key Bypass

[Marshall Brooks]

I have code in my database autoexec that is supposed to disable the Shift Key Bypass UNLESS the database is opened from my development folder.

I am getting ready to release a new update to the database (.accde) file, and I realized that I forgot to set some of the tables to hidden in this view.

I opened the file from my development folder with the shift key and was able to hide the tables.

Then I moved the file to my desktop and was ALSO able to bypass the startup using the shift key.

I went to @isladogs page: https://isladogs.co.uk/improve-security-2/index.html#SB and saw this again:

You will need to close and reopen your database TWICE to ensure the shift bypass has been disabled.

Two questions:

• Is this standard operating procedure for most developers - i.e. I should copy the database to a different location and open it two times before I release it to our users?
• Does this mean that in the past when I failed to do this, any of our users could have bypassed the startup procedures using the shift key, as long as they did it during the first two times that they opened the database? (Unlikely that they would, unless they were really knowledgeable and determined, but It seems that way!!!)

Thanks in advance!!!

 

[arnelgp]

You will need to close and reopen your database TWICE to ensure the shift bypass has been disabled.

it means, the First time is when you first put the code (disabling the Shift-Key) in autoexec and then close the db.
Second time open it again so that the the Autoexec will be Executed (need to allow all macro warnings) and that
the code will run to disable your Shift-key.

 

[theDBguy]

Just my humble opinion but if any of your users are aware of using the bypass key, then they're probably capable enough to do a search and download a freely available utility to reenable the shift bypass key. There's a lot of information on the Internet about that.

 

[isladogs]

This is what my comment about the shift bypass code means:
Add the code to your database and then close it.
The first time you reopen the database, it hasn't yet been implemented so could be bypassed by someone. Don't do that. Just let it run normally and the code will run and disable the shift bypass.
From the second time the database is opened, the bypass sill be disabled. I always do this myself to confirm that before distribution.

However, I made the same point as the @theDBguy about not relying on the shift bypass alone for security as it can easily be reversed externally if you know how. For more info both on this and how to mitigate the effects of anyone doing so, see part 3 of my 3-part series on the shift bypass:

Manage the Shift Bypass Property

The third article in this series shows how to enable or disable the shift bypass property in your Access databases

isladogs.co.uk

 

[Marshall Brooks]

Follow-up - I did read the article. My main concern is preventing direct access to the tables. The article mentions setting them as hidden, but anyone can show hidden objects and see them. Is there a better step to prevent this?

 

[arnelgp]

move your table to a password-protected backend.
and remove the linked table.
use VBA (recordset) when opening a Form or Set the Recordsource
when you open a report.
distribute your db as .accde.

 

[Marshall Brooks]

Getting there!!!

I already distribute as an .accde.

I have a production and a development BE and I switch between them often.

and remove the linked table.

I was using the linked table as the recordsource for the form. I recently changed that to use a SELECT from tablename SQL statement.

Are you saying that if I use this, I no longer have to have the linked table showing in the FE?

 

[Jason Lee Hayes]

Just be careful using the Shift/Bypass technique. Its very common and may give you the impression that it's provides enhances securityI It certainly is worth making use of however with a little RE knowledge the function can be toggled or removed completely. Your data within the tables is ideally where you need to spend effort.

 

[Marshall Brooks]

At least preliminarily, removing the linked table breaks the FE - I get an error when I try to open the respective form.

 

[Minty]

I think the normal method being described here is to only connect/link the tables in code when required, and ensure that the connections are removed when the database or relevant form is closed.

 

[arnelgp]

see this demo, the FrontEnd.accdb has no table or linked table.
open form1 or report1.

 

[Marshall Brooks]

@arnelgp - Nicely done! - but it doesn't work exactly correct for me. If I open the file and click Form1, the database vanishes - it seems to be open - I have .laccdb files on both the FE and the BE, but nothing is visible. If I open the file and open Module1 and then open Form1, it works correctly.

 

[arnelgp]

sorry but it doesn't occur to me what you are experiencing.
you can also set the Recordsource of the form, same as in the report:

Private Sub Form_Open(Cancel As Integer)
'Dim rs As DAO.Recordset
'Set rs = getBE.OpenRecordset("select * from Table1;", dbOpenDynaset)
'With Me
'    Set .Recordset = rs
'    .tFirst.ControlSource = "FName"
'    .tLast.ControlSource = "LName"
'End With

With Me
    .RecordSource = "SELECT * FROM Table1 IN '" & CurrentProject.Path & "\BackEnd.accdb" & "' [;DATABASE=BackEnd.accdb;PWD=arnel];"
    .tFirst.ControlSource = "FName"
    .tLast.ControlSource = "LName"
End With

End Sub

of course you will see both .laccdb for the FE and BE because they are open/in-use.
that is normal for FE/BE (multi-user environ).

 

[isladogs]

The tables can be deep hidden to make it harder to view them

Also, see my example app:

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

The FE has no linked tables and uses disconnected ADO recordsets. The BE uses deep hidden tables with encrypted data

 

[Marshall Brooks]

How to Get the Path to Either the Frontend or the Backend

Databases get moved around. Consequently they have to be designed to (automatically) adapt to the new location. For the Access frontend obtaining the new path is relatively straitforward. strDataBasePath = CurrentProject.Path Recently, I had to relocate the backend so I had to find out how to...

www.access-programmers.co.uk

I think I need to keep one of the tables linked, or the above won't work - however, I have a tbl that we will be getting rid of, so I can use that and just keep that table in the BE.