Go Back   Access World Forums > Microsoft Access Discussion > General

 
Reply
 
Thread Tools Rating: Thread Rating: 2 votes, 5.00 average. Display Modes
Old 12-05-2002, 08:16 AM   #1
PearlGI
Newly Registered User
 
PearlGI's Avatar
 
Join Date: Aug 2001
Location: England
Posts: 125
Thanks: 1
Thanked 0 Times in 0 Posts
PearlGI
Red face Another Security Puzzle!

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)

PearlGI is offline   Reply With Quote
Old 12-05-2002, 09:31 AM   #2
ghudson
Newly Registered User
 
ghudson's Avatar
 
Join Date: Jun 2002
Location: USA
Posts: 6,199
Thanks: 1
Thanked 86 Times in 49 Posts
ghudson has a spectacular aura about ghudson has a spectacular aura about ghudson has a spectacular aura about
Wink

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
__________________
.................................................. ......
Searching this forum or Microsoft.com or MSDN.com or Google is a great way to discover and learn the answers to your Access programming questions.

Well if it seems to be real, it's illusion...

I am using Access 2010 with Windows 7

The
To view links or images in signatures your post count must be 10 or greater. You currently have 0 posts.
function on this forum really does work.

To view links or images in signatures your post count must be 10 or greater. You currently have 0 posts.

.................................................. ......
ghudson is offline   Reply With Quote
Old 12-19-2002, 06:47 AM   #3
lhedquist
Guest
 
Posts: n/a
Lightbulb 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

  Reply With Quote
Old 03-15-2005, 07:48 AM   #4
JinaneKarhani
Registered User
 
Join Date: Aug 2004
Posts: 15
Thanks: 0
Thanked 0 Times in 0 Posts
JinaneKarhani is on a distinguished road
Just wondering,
Can we hide the queries? by code or without it??

thanx ..
JinaneKarhani is offline   Reply With Quote
Old 03-16-2005, 05:52 AM   #5
The_Doc_Man
Happy Retired Curmudgeon
 
Join Date: Feb 2001
Location: Suburban New Orleans, LA, USA
Posts: 14,352
Thanks: 87
Thanked 1,642 Times in 1,524 Posts
The_Doc_Man is a splendid one to behold The_Doc_Man is a splendid one to behold The_Doc_Man is a splendid one to behold The_Doc_Man is a splendid one to behold The_Doc_Man is a splendid one to behold The_Doc_Man is a splendid one to behold The_Doc_Man is a splendid one to behold
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...)
The_Doc_Man is offline   Reply With Quote
Old 06-15-2006, 08:13 PM   #6
Brad
Registered User
 
Join Date: Jun 2005
Posts: 11
Thanks: 0
Thanked 0 Times in 0 Posts
Brad is an unknown quantity at this point
just make a shortcut to the db and set it up to use the runtime environment, that way they can do nothing.
Brad is offline   Reply With Quote
Old 05-15-2008, 06:54 AM   #7
Banana
split with a cherry atop.
 
Join Date: Sep 2005
Posts: 6,315
Thanks: 0
Thanked 90 Times in 72 Posts
Banana is a name known to all Banana is a name known to all Banana is a name known to all Banana is a name known to all Banana is a name known to all Banana is a name known to all
Quote:
Originally Posted by The_Doc_Man View Post
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.
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?

__________________
If relation-valued attributes and arbitrarily complex types are wrong, then I don't wanna to be right!
Founder of 'Blame the Developers First' crowd.


To view links or images in signatures your post count must be 10 or greater. You currently have 0 posts.
Banana is offline   Reply With Quote
Old 05-15-2008, 06:19 PM   #8
The_Doc_Man
Happy Retired Curmudgeon
 
Join Date: Feb 2001
Location: Suburban New Orleans, LA, USA
Posts: 14,352
Thanks: 87
Thanked 1,642 Times in 1,524 Posts
The_Doc_Man is a splendid one to behold The_Doc_Man is a splendid one to behold The_Doc_Man is a splendid one to behold The_Doc_Man is a splendid one to behold The_Doc_Man is a splendid one to behold The_Doc_Man is a splendid one to behold The_Doc_Man is a splendid one to behold
Banana, you are quite right. Which is why you don't ever allow this if you are seriously concerned with the problem at hand.
__________________
I'm a certified grandpa (3 times now) and proud of it.
Retired over one year and survived being home all day with the wife. She must really love me.
If I have helped you, please either click the thanks or click the scales.
The_Doc_Man is offline   Reply With Quote
Old 05-15-2008, 07:11 PM   #9
Banana
split with a cherry atop.
 
Join Date: Sep 2005
Posts: 6,315
Thanks: 0
Thanked 90 Times in 72 Posts
Banana is a name known to all Banana is a name known to all Banana is a name known to all Banana is a name known to all Banana is a name known to all Banana is a name known to all
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?
__________________
If relation-valued attributes and arbitrarily complex types are wrong, then I don't wanna to be right!
Founder of 'Blame the Developers First' crowd.


To view links or images in signatures your post count must be 10 or greater. You currently have 0 posts.
Banana is offline   Reply With Quote
Old 05-15-2008, 11:18 PM   #10
gemma-the-husky
Super Moderator
 
gemma-the-husky's Avatar
 
Join Date: Sep 2006
Location: UK
Posts: 13,769
Thanks: 55
Thanked 1,022 Times in 988 Posts
gemma-the-husky is a name known to all gemma-the-husky is a name known to all gemma-the-husky is a name known to all gemma-the-husky is a name known to all gemma-the-husky is a name known to all gemma-the-husky is a name known to all
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)
gemma-the-husky is offline   Reply With Quote
Old 05-16-2008, 08:45 AM   #11
odin1701
Newly Registered User
 
Join Date: Dec 2006
Posts: 526
Thanks: 1
Thanked 3 Times in 3 Posts
odin1701 is on a distinguished road
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.
odin1701 is offline   Reply With Quote
Old 05-16-2008, 09:30 AM   #12
Banana
split with a cherry atop.
 
Join Date: Sep 2005
Posts: 6,315
Thanks: 0
Thanked 90 Times in 72 Posts
Banana is a name known to all Banana is a name known to all Banana is a name known to all Banana is a name known to all Banana is a name known to all Banana is a name known to all
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.
__________________
If relation-valued attributes and arbitrarily complex types are wrong, then I don't wanna to be right!
Founder of 'Blame the Developers First' crowd.


To view links or images in signatures your post count must be 10 or greater. You currently have 0 posts.
Banana is offline   Reply With Quote
Old 05-17-2008, 06:53 AM   #13
The_Doc_Man
Happy Retired Curmudgeon
 
Join Date: Feb 2001
Location: Suburban New Orleans, LA, USA
Posts: 14,352
Thanks: 87
Thanked 1,642 Times in 1,524 Posts
The_Doc_Man is a splendid one to behold The_Doc_Man is a splendid one to behold The_Doc_Man is a splendid one to behold The_Doc_Man is a splendid one to behold The_Doc_Man is a splendid one to behold The_Doc_Man is a splendid one to behold The_Doc_Man is a splendid one to behold
Quote:
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.
Banana, my friend, that isn't paranoia. That is a healthy assessment of an unhealthy reality.
__________________
I'm a certified grandpa (3 times now) and proud of it.
Retired over one year and survived being home all day with the wife. She must really love me.
If I have helped you, please either click the thanks or click the scales.
The_Doc_Man is offline   Reply With Quote
Old 05-22-2008, 07:39 PM   #14
Banana
split with a cherry atop.
 
Join Date: Sep 2005
Posts: 6,315
Thanks: 0
Thanked 90 Times in 72 Posts
Banana is a name known to all Banana is a name known to all Banana is a name known to all Banana is a name known to all Banana is a name known to all Banana is a name known to all
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?

__________________
If relation-valued attributes and arbitrarily complex types are wrong, then I don't wanna to be right!
Founder of 'Blame the Developers First' crowd.


To view links or images in signatures your post count must be 10 or greater. You currently have 0 posts.
Banana is offline   Reply With Quote
Reply

Thread Tools
Display Modes Rate This Thread
Rate This Thread:

Forum Jump




All times are GMT -8. The time now is 07:01 AM.


Microsoft Access Help
General
Tables
Queries
Forms
Reports
Macros
Modules & VBA
Theory & Practice
Access FAQs
Code Repository
Sample Databases
Video Tutorials

Featured Forum post


Sponsored Links


Powered by vBulletin®
Copyright ©2000 - 2019, Jelsoft Enterprises Ltd.
(c) copyright 2017 Access World