Solved: Access Protection

[Aussiebear]

Hypothethically speaking, if I somehow managed to build an Access database,( well you can stop laughing I just might fluke it), what stops somebody with a little bit of VBA knowlege from simply walking in the back door?

Not that any database that I'm likely to be involved in, would be highly critical, but I would like to keep the data entry level people on their side of the fence and those who needs to maintain the database on theirs, if you catch my drift.

[Marcster]

I would like to keep the data entry level people on their side of the fence
and those who needs to maintain the database on theirs
You could use 'user-level security'
You define what kind of users to access/change what
parts, of the database.
Have a look in the help file for this, is this what your after?.

Marcster.

[Aussiebear]

Possibly..... this'll keep the good guys out. At work we have those guys who see a computer as an object to to be feared, they'll use it to enter data as long as you don't ask them to anything more than that, then there's those guys who type a bit, can follow simple computer instructions and have a very basic understanding that you don't take a hammer to the computer, just because it didn't predict the winner of the next horse race. And there's the one % who can actually use the system, and know some programming. The trouble is, some of the guys who should be on the "just enter the data" list, know some of the short cuts.

So are you suggesting that setting user levels will stop these guys?

What I really need is two magic hands that appear out of the monitor that'll choke the living daylights out of the user who is looking in areas he's not supposed to be in.

[OBP]

You can't stop a very determined, very good programmer from messing with your database. But using "User Group" security makes it very difficult for them.
Added to that you can also "password protect" the access to your VB Editor and it's modules.
If you need any help I have "secured" quite a few databases.
The ultimate is to convert the secured database to and .MDE database, this also protects the forms and queries as well as they are not in the database at all.

[XLGibbs]

You can also change the attributes of stuff you don't want seen by those not "in the know" by changing their attributes to hidden.

On normal run time, they are still there and can be used by the database, but remain unseen.

An experienced programmer would know to hold down the shift key when opening the DB to make all hidden objects visible or to go to the options menu and change the settings to show all objects.

[Aussiebear]

Absolutely true.... In my case it was by accident that a guy said "if you hold down the shift key as your program starts...." So this leads to the question, can you disable the Shift key shortcut but still maintain control?

Are there any basic VBA type shortcuts that one needs to be aware of in trying to protect one's software?

One could go to the extent of making something an MDE but as I understand there's an english website which can unlock an MDE but not the code contained within.

[geekgirlau]

Yes, you can disable the Shift key, but you need to create a back door entry so you can still make changes.

Generally you either create an AutoKeys macro that runs code to enable or disable the shift bypass when you press a specific key combination, or you use the /cmd option on the startup line of your shortcut to do the same thing. If you do a search on "shift bypass" you should find lots of code samples for this.

[Tommy]

You could encrypt the data, move the data from a working table to a lets see whats here table (throws the people that look for a loop), reverse when your programs are loaded completely, no load no unencrypt no useful data that can be seen with the naked eyes (or even glasses).

[Aussiebear]

Tommy, What ever you just said "has just left the building". Can I have a translation?

P.S. I'm struggling with the concept that 2 + 2 does not equal 5, so baby steps please when you do explain.

[Tommy]

LOL
This will only work if the data is less than 5 meg. Otherwise the performance hit will get pretty bad.

You would have a table that I would call "Work". This table gets created each time the application is opened and deleted (dropped) each time the application exits. when the table is created I select * from "data_table". I itterate through each record from my select statement and decrypt the data. For example if the data is string, replace(string,"Z","QWE") in other words replace each character/group with something only known to you. (Of course it will be in your code but if some one messes with it that much you need them woking for you.) Insert it into the working table. This is the table that all selects etc are done on so in reality it contains the human understandable data. When the application goes to close, select * from Work, replace(string,"QWE","Z") the information (re-encrypt it) , insert/update the data_table and drop the Work table.

If the work table exist when the application opens show a message box explain why your application doesn't know what to do since they messed with the code, and shut down. If the work table does not exist when the query(s) is/are run do the same, tell the user your application is now confused and will shut down because something was changed without your permission.:devil2:

Of course there is always code in one database and data in another at another location. You select the data from the remote and insert it in the local database, depending on the user. This way the loss of data or data corruption can be kept to a minimum. Which is like what I posted above, just the encrypted table is someplace else.

If some one tries to figure out what is going on, (power user is what I call them) it would become too difficult to deal with, especially after all the confused program messages.:rofl:

[Aussiebear]

Tommy, you have been watching the management of the company I work for.....

Seriously though, I may just have to go down the track of an MDE. My thanks to those who contributed to this thread.