Prevent copying database to another PC

[MadTom]

I'm looking for an approach to stop someone from sharing a database. I'm looking at using ComputerName = objNetwork.ComputerName and UserName = objNetwork.UserName saved in a hidden table and then checking saved data against current data. I believe I can figure out how to do this, but looking for different suggestions.
Thanks!

[orange]

You may get some ideas from these links from Daniel Pineault.
Get Processor ID
Get Computer Name

or Custom Property from Allen Browne

For hard disk serial

' Purpose: To get serial number of computer harddrive
' Procedure Kind: Function
' Procedure Access: Public
' Return Type: String
' Author: Bob G from https://www.utteraccess.com/topics/1948759
' Date: 02-Dec-20
' ----------------------------------------------------------------
Function DriveSerialNumber() As String
    Dim FSO As Object
    Set FSO = CreateObject("Scripting.FileSystemObject")
    DriveSerialNumber = Format(CDbl(FSO.Drives("C:").SerialNumber))
End Function

Good luck

[Micron]

Not enough info. What kind of db? accde, mde? Runtime? Regardless, is it split? You would set the location in the table or the user would upon first time use?
Best chance would be hard coding in accde or mde rather than a table - especially if the db is split.

[isladogs]

You cannot prevent anyone sharing a database i.e. copying it to another computer.

However you can take steps to help prevent that copied database being run on another computer.
What you have suggested will provide some limited protection though it would be relatively easy to circumvent.
Using a combination of items specific to the first computer such as data based on CPU ID, motherboard ID, hard drive number would be more secure.

However, whilst you can deter piracy, it would be very difficult to make any such system 100% secure.

[MadTom]

Thanks for the reply ! It gives me something to work on. I know it's not 100%, but with other methods should make it very hard for the average person.
Tom

[isladogs]

In case I've not provided the link already, see my two part article Improve Security in Access Databases.
The second part includes an example app with all code needed to test the various steps described in the article

[MadTom]

I've got my code up and running, I have what I believe I need.
Question. How secure is this code to hide tables?
I will also disable what I need and split my database and make the FE a accde database.

Public Function hide_tables(hide As Boolean) As Boolean

    Dim tdf As TableDef
On Error GoTo errHandler:
    For Each tdf In CurrentDb.TableDefs
        If Not (tdf.Name Like "USys*" Or tdf.Name Like "tblB*"  Or tdf.Name Like "~*") Then
            If hide = True Then
                tdf.Attributes = dbHiddenObject
            Else
                tdf.Attributes = 0
            End If
        End If
    Next tdf
    hide_tables = True
exitSuccess:
    Exit Function
errHandler:
    Call display_error
    Resume exitSuccess
End Function

[isladogs]

The simple answer is ... slightly less secure than it might have been by virtue of you publishing your code.

It will be reasonably secure from within the app itself providing you also lock down the ACCDE file including:
- hiding the navigation pane/ribbon & QAT
- disabling the shift bypass,
- disabling full menus & default shortcut menus
- removing Access Options from the File menu

However, anyone who knows how to do so will still be able to reverse all your security measures externally

[MadTom]

Would someone with expert knowledge have all access to code and tables? even with all options above?
Thanks for your comments!

[isladogs]

Once you have compiled your code by creating an ACCDE, it is completely inaccessible. There is a company (EverythingAccess.com) capable of reverse engineering the ACCDE back to an ACCDB but they require proof of ownership before proceeding and their services are fairly expensive.


If you do all the security measures outlined in my article, the tables will also be secure from most Access users. However a skilled and determined hacker with sufficient time and motivation will still be able to view the table structure and data from outside your application.


NOTE: I have no intention of explaining how that can be done in a public forum. I suggest you also remove your code from post #7.

[CJ_London]

you haven't mentioned queries.....

queries give a view of the tables, hidden or not

unfortunately, you can't hide queries

[isladogs]

As Ajax correctly states, queries cannot be 'deep hidden'.
That issue is overcome by not using saved queries.
Instead use sql in your vba code...which will be inaccessible once you create an ACCDE

[CJ_London]

any hard coded text such as a sql string or password can still be identified in a .accde if you know what to look for

really depends how far you want to go. You could store the query sql in a hidden table, perhaps hashed as well, then have a function which receives the query name as a parameter and returns a recordset.

thinking about security after you have developed the app is always going to be a bit of a mashup of what you can and can't do. Better to have built it in as a design requirement before development commences.