Hacking BE

[KenHigg]

I know this has probably been asked before but I thought I'd ask again; If someone copies a .mdb with the tables in it how can they be stopped from attaching to it and pulling out the data. I know that you can put a simple db password on it and I know the can be slowed down by putting MS Access security schema on it but these are not bullet-proof. Any other ideas? I was wondering if some kind of limit could be applied say something like at the OS level that would only allow the file to be opened from workstation that is in the network security list - ?

 

[wazz]

encode? not sure how easy it is to decode though.

 

[KenHigg]

Hi Wazz, Are you talking about making an mde?

 

[Banana]

wazz, I understand they store encryption key with the database; basically putting your key under the doormat.

I'd roll out a custom encryption solution, where the user supply the key (without knowledge that they are doing so, and what they entered is hashed to something else to become the actual key) but I suspect that it would be quite bad on performance, depending on how you implemented (e.g. whether only at open/close or for each table accessed or whatever)

One potential idea but entirely untested is to use RunAs so you can place the BE in a restricted folder that nobody has permission to from the Windows, then using the same principle above, user log in with a password which becomes a hash and is the password for a dummy Windows account that has the permission to that folder and opens the database on user's behalf.

I don't know much about Windows security, but if there are means to guarantee that dummy account is within a domain or a certain computer, then this would be the avenue to explore.

A word of caution, though, as someone accustomed to sudo, RunAs blow giant elephant trunks and there were problems with it (e.g. some programs will not run/install correctly even with the full privileges granted by RunAs). I briefly tested an unsecured Access, and it did seem to work OK.

 

[DJkarl]

I know this has probably been asked before but I thought I'd ask again; If someone copies a .mdb with the tables in it how can they be stopped from attaching to it and pulling out the data. I know that you can put a simple db password on it and I know the can be slowed down by putting MS Access security schema on it but these are not bullet-proof. Any other ideas? I was wondering if some kind of limit could be applied say something like at the OS level that would only allow the file to be opened from workstation that is in the network security list - ?

If you are looking for a bullet-proof solution then I think you may need to venture outside of Access. You could put code in the BE to check for current location but of course this can be bypassed. I think as long as Access requires full permissions to utilize it there isn't any way to fully secure your BE.

That being said....

When this is a concern for me I've locked down the front-end as much as I could and have removed all linked tables to the backend, I either relink them as needed using VBA, or skip linking them all together using the SQL IN clause. The connection strings I need are stored externally in encrypted files and read into memory on initialization, thus if some user is going through the front end with a hex editor trying to glean information they won't come up with much. I figured the best way to secure the backend from the users was to hide its existence from them.

 

[wazz]

in access: tools-security-encode/decode.

edit: i have no practical experience with this, just stuff i've read so you'll have to check things out and follow other posts...

- the 'ol vba programmer's ref book says encoding is the only way to stop people from accessing data via non-jet methods (shared level security will ask for password if people try to access via odbc).
- gary robinson's security book seems to say encode is pretty good security (encode the .mdb then make that an .mde) but there can be a big performance hit up to ~15% slower!
- as for OS though, Robinson seems to talk about that every 5 minutes. i don't remember the details but the way i remember it is basically, track every user and secure every folder in the directory path until you hit the .path!

 

[DCrake]

Simple Software Solutions

One trick I tend to do is to hide all the tables and queries in the back end and set the show hidden property to False.

Now of you open a new mdb and try and import/link to the back end it will not show you and hidden objects.

CodeMaster:

 

[KenHigg]

Hum... So if you make and mde and disable the shift key there is no way to see tables. Thanks, I give it a whirl...

 

[wazz]

hiding is a good idea. something i worked on a while back:

Private Sub cmdHideTables_Click()
'See "Set Options from Visual Basic" in vba help.

On Error GoTo ErrorHandler

    Dim obj As AccessObject
    Dim db As Object

    Set db = Application.CurrentData

    For Each obj In db.AllTables
        Application.SetHiddenAttribute acTable, obj.Name, True
    Next obj

    Application.SetOption "Show Hidden Objects", "False"
    Application.SetOption "Show System Objects", "False"

ErrorHandlerExit:
    Set db = Nothing
    Exit Sub

ErrorHandler:
    If Err.Number = 2016 Then 'Can't modify properties of system tables.
        Resume Next
    End If
    MsgBox etc...
    Resume ErrorHandlerExit
    
End Sub

 

[KenHigg]

Cool - So now the only way to get to them is to by opening the mdb in a second mdb and looping through the table objects, etc... ?

 

[Banana]

However, what can be done, can be undone as well. I'd bet it'd just be a task of looping through the tables and unhiding it, no?

You could just deny permissions to tables and queries using ULS and force user to only use forms. To do so, forms would have to run with owner's permission instead of user's permission so forms can access tables and queries for its work.