Securing Database 4

[Mr2006]

I have a database that reside in the common drive. I did not slplit the database. It is used by multiple users. it has not reached 10 users at any given time. I would like to pprevent any user from accessing the tables directly by pressing f11 or by pressing the shift key when strting the database.

Is there a way to do this?

Thanks
Mr.2006

 

[MajP]

I did not slplit the database.

Why not? Bad idea. You are begging for a corrupted database.

You can disable the shift bypass. Something like

Function ChangeProperty(strPropName As String, _
 varPropType As Variant, varPropValue As Variant) As Integer
' The current listing in Access help file which will
' let anyone who can open the db delete/reset any
' property created by using this function, since
' the call to CreateProperty doesn't use the DDL
' argument

 Dim dbs As DAO.Database
 Dim prp As DAO.Property
 Const conPropNotFoundError = 3270

 Set dbs = CurrentDb
 On Error GoTo Change_Err
 dbs.Properties(strPropName) = varPropValue
 ChangeProperty = True

Change_Bye:
 Exit Function

Change_Err:
 If Err = conPropNotFoundError Then ' Property not found.
  Set prp = dbs.CreateProperty(strPropName, varPropType, varPropValue)
  dbs.Properties.Append prp
  Resume Next
 Else
  ' Unknown error.
  ChangeProperty = False
  Resume Change_Bye
 End If
End Function
Public Sub subSetAdminProperties()
   ChangeProperty "AllowBypassKey", dbBoolean, False
End Sub

 

[TheTomCat]

There numerous ways you can protect a database. I have mine protected at least four (4) different ways.

First, you should definitely consider Spliiting your database. Then with the Front End you could disable the Shift ByPass. On mine I have a command button that you have to enter the correct password to enable the Shift ByPass.

You can set a password in a Module. In a Module design, go to Tools\Design\Protection. Input a password.

Also, and probably the best way, you can make the Front End an .mde file. Be Careful though. Make sure you save and protect the original file. You cannot change anything in an .mde file. You would need to make any changes, etc. in the original file and then overwrite the .mde file.

If you ever get into distibuting a database elsewhere, I would recommend the .mde.


Hop this helps!

Thomas Bailey
a/k/a TomCat

 

[lameid]

Mr2006,

As it seems you know it is possible, you can specify the startup properties (tools menu, startup) to not allow the display of the database window, Not allow menus and not to allow Use Access Special keys. That keeps them from getting to the tables unless they hold in the shift key as the database starts.

As others have pointed out you can keep this from happening by setting the database AllowBypassKey property to false. The probelm here is that it may not exist by default which is where MajP's code comes in.

subSetAdminProperties sets the properties of the current database to not allow it.

I also aggree that splitting the database is the way to go.

If no one can get to the database window, they can't look at the linked tables to see where the backend is. This at least protects the data by obscurity.

A moderately savy user could link to the tables in your common file as it is. A truly savy user could change the allowbypass key property unless you use Access security to prevent it. I usually ensure the 'admin' user at most has Open/Run permission to the database. Of course that is the user named admin and not the administrator or all powerful user.

 

[Mr2006]

Thank you so much for all the great feedback. I was planning to split the database but since we will move to different database very soon using SAP.net, I decided to wait and keep it the way it is. But I am interested in disabling the shift bypass key and creating a way to enable it when I need to access the tables. I am not sure how will I do this.

Can you instruct me on the steps to do this?

Thanks
Mr.2006

 

[jsteph]

An add-on method I use to lock down an Access database is to follow up the standard security with this method...it's a bit more work but it has confounded several so-called 'access hackers' in our organization:

1. Go through the full Access/Jet securing process as directed in many of the faqs here and MS whitepapers.

2. Take your database .mdb file and your secure .mdw file and rename them to something inconspicuous with an unexpected but common extension, and stuff them somewhere like in the windows/system32 directory. For instance, gxi.dll and gxiw.dll. Where gxi.dll is the front end and gxiw is the secure .mdw.

3. Create in vb a short exe that calls the msaccess.exe of the correct version (there are api's to find the Access directory and get the correct access version where multiple versions exist, though in our environment we image client machines with the standard Office install locations).

Then in the vb code, use the command line, calling msaccess.exe with the /wrkgrp switch pointing to the gxiw.dll, and then the mdb to open is the gxi.dll. You can use the CreateProcess api or simply Shell().

In your deployment script you always place these ".dll" files in system 32, then you can place this 'proxy stub' .exe anywhere. Now users only know to click the .exe. They have no idea what actual .mdb is being called, and there are few telltale traces.

One trace is that an .ldb is created in the system 32, and a smart hacker might look for that. But to hack he still needs the secure.mdw file, which you could even rename to something unlike my example, so there isn't a clear relationship to this mysterious .ldb file in the System32 directory. Another telltale is the registry's MRU list, but I have even used Registry apis to clear this list.

So...*if* you want another level of obfuscation security, this one has worked well for me.

--Jim

 

[TheTomCat]

Mr2006,

Do you still need the Shift ByPass information along with a way to enable it?



Thomas Bailey
a/k/a TomCat

 

[lameid]

The way I re-enable the bypass key is to open the database programmatically from another file.

Instead of the following

Set dbs = CurrentDb

Use something like:

Set dbs = Opendatabse("C:\My Documents\Example.mdb")

The alternative would be to provide a function to re-enable it using the existing function.

Just set it to true instead of false.

ChangeProperty "AllowBypassKey", dbBoolean, True

As to how you want to allow it I leave it up to you... Perhaps a button could becomee visible if your username is logged in

 

[TheTomCat]

I enable my ShiftByPass key with a Command button on the Main Switchboard. Just click on it, enter a password, then close and re-open with the shift key held down.

I can supply the code, etc. if this is what you want.

Thomas Bailey
a/k/a TomCat

 

[Mr2006]

TheTomCat,

That will be great if you can supply the codes and I will work on it this week.

Thanks

 

[TheTomCat]

First, make a backup of your database just in case something goes wrong.

Create a new Module. You can name the Module anything you want. Mine is just named ByPass. Place the following in the Module:

Public Function SetProperties(strPropName As String, varPropType As Variant, varPropValue As Variant) As Integer

On Error GoTo Err_SetProperties

Dim db As DAO.Database, prp As DAO.Property

Set db = CurrentDb
db.Properties(strPropName) = varPropValue
SetProperties = True
Set db = Nothing

Exit_SetProperties:
Exit Function

Err_SetProperties:
If Err = 3270 Then 'Property not found
Set prp = db.CreateProperty(strPropName, varPropType, varPropValue)
db.Properties.Append prp
Resume Next
Else
SetProperties = False
MsgBox "SetProperties", Err.Number, Err.Description
Resume Exit_SetProperties
End If
End Function


On your Main Switchboard, create a new Command Button and name it: bDisableByPassKey

Place the following in the On Click Event:

On Error GoTo Err_bDisableBypassKey_Click
'This ensures the user is the programmer needing to disable the Bypass Key
Dim strInput As String
Dim strMsg As String
Beep
strMsg = "Do you want to enable the Bypass Key?" & vbCrLf & vbLf & _
"Please key the programmer's password to enable the Bypass Key."
strInput = InputBox(Prompt:=strMsg, Title:="Disable Bypass Key Password")
If strInput = "Password" Then
SetProperties "AllowBypassKey", dbBoolean, True
Beep
MsgBox "The Bypass Key has been enabled." & vbCrLf & vbLf & _
"The Shift key will allow the users to bypass the startup options the next time the database is opened.", _
vbInformation, "Set Startup Properties"
Else
Beep
SetProperties "AllowBypassKey", dbBoolean, False
MsgBox "Incorrect ''AllowBypassKey'' Password!" & vbCrLf & vbLf & _
"The Bypass Key was disabled." & vbCrLf & vbLf & _
"The Shift key will NOT allow the users to bypass the startup options the next time the database is opened.", _
vbCritical, "Invalid Password"
Exit Sub
End If
Exit_bDisableBypassKey_Click:
Exit Sub
Err_bDisableBypassKey_Click:
MsgBox "bDisableBypassKey_Click", Err.Number, Err.Description
Resume Exit_bDisableBypassKey_Click

Enter your password in place of "Password" above.

That should do it. Now open your database, click on the new button you made and enter your password. Then close the database and re-open with your shift key held down. Then click and type in a wrong password. Close, then try to open with the shift key held down. It should NOT work.

Hope this helps.

Thomas Bailey
a/k/a TomCat

 

[lameid]

One major comment about using the password in code...

Unless you make it an MDE (unless you use 97 or earlier and can set permissions on modules), anyone can import the module and see the password. That can be worked around with the database permissions I mentiond for the database object. You would have to be some user with more permission for the property to be allowed to be set. Using an MDE is a major reason to split the database because you would want to keep a copy to make changes to the code and you would not want to overwrite your data.

You might also put it on a button that is not visible. On the form's open event, if environ("username") is equal to your username, make the button visible. Then the click event is my second code example in my last post which uses MajP's code post...

ChangeProperty "AllowBypassKey", dbBoolean, True

 

[TheTomCat]

lameid is definitely correct. I distribute my application as an .mde a,long with a couple of other protections. I would not do it any other way.
If not an .mde, anyone can get to the code and password.
My way, the Shift Key is Disabled unless you know the correct password to enter in the Command Button on the Main Switchboard and it's .mde.

Thomas Bailey
a/k/a TomCat