Another Security Puzzle! (1 Viewer)

I thought I had the security issue sorted!

This is what I've got.

Backend - located in hidden directory, database password protected, shift disabled, shortcut keys disabled.

Frontend - distributed as MDE, shift disabled, shortcut keys disabled, database window hidden etc.

To prevent unauthorised users accessing the FE the first thing it does is to validate the userID (using network name API). If invalid the FE automatically closes.


Now you may think that this is secure, but someone has found a loop-hole (wasn't malicious, I challenged them!)

They simply created a new db and ran the import wizard (yes, import not link) and imported all my tables from the FE. But this didn't import the tables, it created links straight through to the BE, completed by-passing all security. Once there, they could add their userID to the table of valid userIDs and enter the FE legitimately.

Can anyone see a way of preventing this? (Without using user groups or restricting network access)

Your attempts at securing your db are only preventing the user form accessing your db objects from within the db itself.

One trick you can try to prevent someone from importing your db objects is to hide the objects. Right click a db object (table, form, etc) and select the Properties option and then check the objects "Hidden" Attributes: box.

Assuming a user has not turned on the "Display Hidden Objects" option (Tools / Options... / Show Hidden Objects) in Access on their computer, they will not "see" your hidden objects when the try to import them.

Obviously this is not bullet proof but it might "fool" the average user.

You must use Access security (workgroups and permission's) if you want to prevent unauthorized use (or abuse) of your databases.

HTH

security

I have been struggling with the same problem that concerns users being able to create a new database and import or link to
attached tables in a user level "secured" database. If I set the
user permissions high enough to allow them to add, edit
and delete through a form "layer", these permissions also
allow them to link and import tables to a new database-
which I don't want them to be able to do. Since I can't
find any info in the MS security faq that relates to this,
I have been considering using hidden objects as a
security measure. At least with Access97 you cannot simply view the attached tables by clicking on the show hidden or show system tables option in the user created blank database and then import from the "secured" database.

Function MakeHiddenAttachedTable()
Dim strDatabaseName As String
Dim strTableName As String
Dim strAttachedTablename As String

Dim DB As Database
Dim td As TableDef

Set DB = CurrentDb
strDatabaseName <ODBC string/database>


Set td = DB.CreateTableDef("<tablename>")
td.Connect = strDatabaseName
td.SourceTableName = "<tablename>"
DB.TableDefs.Append td
td.Attributes = dbHiddenObject

Note: the hidden attached tables are only temporary with this attribute meaning that if the database is compacted and repaired, the attached tables are deleted! Before the compact and repair is initiated I have to unhide the tables td.attributes = 1 or relink the attached tables after the compact and repair.

I wondered if you had found a more robust/elegant solution??

LH

Just wondering,
Can we hide the queries? by code or without it??

thanx ..

Just a thought, but ...

Can you determine the name of the FE database to see if it is an .MDE file? And can you check the properties of the DB as well, to see if the DB thinks it is consistent with your original MDE or not?

Or, you can try this approach: Inside the BE db, have a hidden table. Inside the FE db, if you have a startup form, have it trigger a quick (?)computation of the FE db file's checksum. Pick any algorithm you like. Make absolutely sure you compile the code and hide / remove the source before you make the "distributable" copy. Compare the computed checksum to a checksum you computed yourself externally for the "true" copy of the MDE file. Since you can store this in the BE db, it doesn't change the FE checksum once you have computed it.

If the users just copy the MDE, that should not change the checksum. If they IMPORT it, that will most likely change a lot of the internal pointers because of the order in which they appear - plus the fact that the date info in the TableDef, QueryDef, Form, and Report Document Defs will all change. THAT will cause the checksum to change drastically. Then have that code simply refuse to run. Let it do a QUIT command.

If they imported the DB as an MDE file, they have to know what to not import in order to get around this. One thing you could do is make this a subroutine in a general module and have your forms "randomly" compute this in some sort of thread. Then put something else in the module that if they don't have, the DB won't run at all. If the DB is converted to MDE format with the source code removed, they CAN'T be selective.

Then the only trick is that you have to be able to run the code in a way that it knows who you are and so that it won't clobber YOU when you are working on the master copy. That will let you compute the correct checksum for the file and store it in the reference table in the BE db. OR maybe define a new property of the DB and store the checksum there (though that might change the checksum if it is a property of the FE - but not if it is a property of the BE!)

Now, how to do checksums... If you can link to the TCP/IP library and see some global entry points there, you might be able to use an MD4 or MD5 hash function. A trip to you local bookstore for a reference to the TCP/IP portion of your Windows might be in order. A book on WinSock programming MIGHT have a reference you could use. Or do a net search to find the entry point names and how to use them. Otherwise, you can roll your own.

Open the file for input as a binary file. Input it a byte at a time. Compute the checksum as the sum over all bytes in the file of some formula. Make it a LONG integer checksum, that will give you 32 bits to play with. Any checksum with multiple multiplicative components will do just fine. Make sure that you test for (and ignore) math overflows in each step of the computation. Technically, most checksums are the low-order 32 (or 64 for the long sums) bits of the true checksum. You could make the sum

cksum = cksum + 1 + byte + ( 32*byte) + ( 2048 * byte ) + ( 32768 * byte )

where despite the nomenclature, each of the named variables is a LONG but you load the "byte" variable one byte at a time from the file. (In other words, extend the variable size - but do NOT extend the sign bit of the byte for this formula - it adds a lot of complications.) For the purists, this is an

x^0 + x^1 + x^5 + x^11 + x^15

checksum. But other formulas are possible. Pick at least a couple of odd-numbered powers in the range 0-16 and add in your favorite constant. The biggest problem is that since Access VBA is not fully compiled (it goes to pseudo-code), this won't be as fast as a canned, external program.

(HINT: This is why I suggested you try to get to your TCP/IP stuff to find one of the hashing functions built-in to windows NT and later...)

just make a shortcut to the db and set it up to use the runtime environment, that way they can do nothing.

The_Doc_Man said:

Or, you can try this approach: Inside the BE db, have a hidden table. Inside the FE db, if you have a startup form, have it trigger a quick (?)computation of the FE db file's checksum. Pick any algorithm you like. Make absolutely sure you compile the code and hide / remove the source before you make the "distributable" copy. Compare the computed checksum to a checksum you computed yourself externally for the "true" copy of the MDE file. Since you can store this in the BE db, it doesn't change the FE checksum once you have computed it.

Click to expand...

I thought I had asked this before, but couldn't find that post. I was told that because of how MDB/MDE may change from one execution to next, checksum would invariably fail. For example, if a FE has a local table that may be updated by the end-user legitimately, it would cause checksum to fail, no?

Banana, you are quite right. Which is why you don't ever allow this if you are seriously concerned with the problem at hand.

Ok, as long there is nothing in the FE that changes (e.g. no updateable local tables), the checksum will always work then? That's another point I'm not quite clear as I recall Pat Hartman saying that because it's basically a file server, it may store internal pointers and variables and whatnots which can change the checksum, correct?

an mde is pretty secure - most apps let users see the table structures - unless its a pre-packaged commercial app, its probably not worth getting hung up about. Its not so much of a problem if this is a one-off app for a client The only reason not to see the data, is that you are concerned users may edit directly into tables

most commercial apps let you do this via odbc links, if users would be so daft

however, if you want to limit the number of users then (eg for licensing terms) then you either need some sort of installation routine/hidden file/ etc prevent it running on other than designated computers. or have some sort of logon procedure controlling the number of active users (probably better)

To prevent something like this, I use a blowfish encryption algorithm to encrypt data stored in a user table. If the user finds a way to open it, they just see gibberish.

Encryption password and etc. are stored in the code, so not accessible (or at least nowhere near as easy).

This can cause some slowdown if you have a huge table, but if not then it shouldn't be noticeable.

However - the problem is that if a user has direct access to a table and you don't want them in there, that's bad. So if they can import and look at/edit tables, that's bad.

The problem is that Access doesn't require you to re-enter a password for a link which contains a reference to a password protected back end. This, in my opinion, is a huge security flaw in Access. Nothing we can do about it other than to take ridiculous steps such as encrypting data, etc.


The other thing that you can do is to remove ALL links in the front end before closing, and then have it re-link tables on startup using code. Obviously check the user table first and if no access, remove that link then close. If access is enabled, then it would link the rest of the necessary tables.

This is a pain, but it is one solution.

Regarding the flaw of not prompting for password when you close database (but not Access itself) then re-open it, I've decided to use a hack which when then the form is closed, it forces Access to quit entirely. Not elegant but at least it closes the flaw. This is also simpler than deleting all links then re-creating them which has their own set of problems.

The problem for me, however is not validating users, as OBDC links themselves are pretty secure and I can store all credentials within the backend, so there is nothing of interest in the database itself; the problem is verifying that the database has not been tampered with (e.g. someone has introduced a keyboard logging into the database). Hence, the idea of requiring a checksum at log-on would help assure that the FE wasn't tampered with. But that doesn't guarantee that there won't be a keyboard logger monitoring the entire system, which is a Windows administration issue, not an Access issue.

My paranoia stems from the fact that connections will be made from laptops at various locations outside the company's secure network (we do some on-the-road works). I can secure the line, but not the endpoint.

My paranoia stems from the fact that connections will be made from laptops at various locations outside the company's secure network (we do some on-the-road works). I can secure the line, but not the endpoint.

Click to expand...

Banana, my friend, that isn't paranoia. That is a healthy assessment of an unhealthy reality.

Another point...

I can write out a code to do a checksum on the application and submit it to the server for validation.

But I have no guarantee that the checksum being sent to the server is actually the checksum of the application; it's trusted and that could be a bad thing™.

Is there any way to guarantee that the checksum is indeed the checksum of the application?