My conclusion with regards to access (would love to be proven wrong by the way) is that the only viable security model is "security for show". Like when people play a recording of a barking dog in their house and have lights on timers when on vacation. With access, you can make it *look* secure, but it is trivial for anyone with motivation to circumvent your procedures.
FWIW- I do not think Access an appropriate vehicle for a commercial application. It's great when you just need some kind of in-house software or maybe as an interface for your clients, in which scenarios, the users already has an incentive to keep the application working and gain nothing from stealing it. Well, at least relatively.
That said, if you really wanted to lock down the application, I'd probably do the following:
1) Use API calls to check the Windows logon and whether the computer is a member of certain domain. Best to call the Domain Controller so there's no need to embed any information about the domain itself in the application. Just need to match the data from API calls to the DC's description of the computer. This by necessity requires VPN for external connections as well. Even if we don't have AD, something similar can be setup.
2) Don't store data in Access at all. Use a server RDBMS such as SQL Server, Oracle, DB/2, MySQL, PostgreSQL, whatever and require log-on by the users so the password isn't stored. The user & password shouldn't be stored and can be enforced in both client & server by using DSN-less connection for the client and implementing MSysConfig table in server.
3) Convert to MDE/ACCDE/ADE.
Few more points:
1) It's not that Access security is flawed. It's simply the nature of having a file-based database. An application compiled in Visual Studio using SQLite or SQL Server Compact Edition would have precisely the same problem. This is because the direct access to the data file is required so it's only a matter of cracking the protection. Server RDBMS circumvent the problem entirely by having a daemon manage the data files and thus users do not require access to the data file to use it- they just need to interact with the daemon. Though doing it in Visual Studio would have more flexibility in how to implement the protection, it still doesn't change the fact that we're just delaying the inevitable.
2) It's actually easier to decompile an .exe than it is to decompile a .mde/.accde/.ade. This is because the decompiling for machine code or .NET CLR are documented and more widely known whereas there is no public documentation at all for the VBA's p-code (e.g. the compiled code) and there's certainly no symbol table available. So IP relating to VBA code is actually quite well-protected. Of course it's still up to us to protect the tables & queries.
3) We can further restrict the access to the data by configuring the network in such that it only accepts connection from a certain family of IP addresses so it need not be exposed to the whole company's network or even the internet. This step, of course, is probably mandatory for any reasonable security setup, even if the company is totally uninterested in securing the database and trusts the users.
EDIT:
4) Many of protection schemes I've seen around usually miss this crucial point: The keys, passwords, whatever, are always stored plaintext whether you store it in a table, in VBA as a string literal or as a object's property. Thus that information can be gotten by merely opening Notepad on the file. Some may attempt encryption but encryption by design is two-way, so it can be crackable. If it must be stored, use a hash instead. The description in #1 illustrate the point of not storing by doing a comparison between two different calls into Windows' API, one against the logon and other querying the DC. VBA code needed to do this can be protected much more effectively than when it has to compare with a value in table, in a object, or a string literal.
5) I've posted it before but I'll do it again because it's worth emphasizing:
So even if we had 4096-bit RSA or the top-of-line encryption available to us, it doesn't guarantee that hackers will not find an easier way to get the information.
END EDIT
So, yes, Access, like any other programs & files can be secured. It actually depends more on the operating system & the network rather than within the file itself. After all, Excel & Word's "protection" suffer from exactly same problem- the password are stored inside the file and is thus available for taking.
