Security..Is there another way?

securing the database objects have different ways:

1. Password protect the database
2. Password protect the VB codes
3. Disable allowbypasskey
4. Make MDE file for versions 2003 and previous
5. ULS

MY PERCEPTION:

a. the simplest way to protect is by password protecting
b. Allowbypasskey diabling is a protection done by vb code
c. by making the MDE file, the forms, report, dap, macro, and modules
are locked thereby it cannot be opened for editing or for opening.
d. by making ULS, the objects are locked by access, I think this goes by
code again and we setup its password.

MY CONCLUSION:

Therefore, protecting the database objects were done thru coding matched by password. So therefore, maybe there is a way that we can make our own CODE to lock the database objects.

And I think our gurus here in this forum might help us out with that code.
Can we do this?

To answer your question, all of above could be done in code... but why reinvent the wheels for what is essentially an administrative task? Once you've set up the security, then you're pretty much done with it and don't need to manipulate it via code.* Maybe I'm not understanding your goal here.


* A good reason to provide the security functionality via code would be in scenarios where we have multiple sites and it's easier to provide local administration of users/groups without giving the local administrator the unrestricted privileges as a developer would have to the file, but that's specific to the case of adding/promoting/demoting/removing users rather than managing the security overall, which still would be a one-time job.

yes I agree that setting up the security is an administrative task.

What I want to point out is that, if there is a simplier way to protect the database!

Like MS Access 2007 which does not use ULS but rather more empowered encryption database password security. Though it still employs ULS but for previous versions.

I guess that can be achieved because you have said "all of above could be done in code".

Can we lock the database objects with our own code and not thru ULS?

Now I see what you are asking.

Short answer: No.


Long answer: The problem is to effectively secure a file you must ensure that the code does a check on the permissions before it does *anything*. Jet already does this and as such there is no such as "unsecured mode" or "security turned off"; it's always on, though the default mode would be "let anyone in the world edit whatever they want." and needs to be changed to something to "only I can design it and only those bunch of people can access it and keep out the rest." mode.

In order to implement our own encryption scheme, we would have to wrap every objects with our custom permissions. The only way to do this is to go through the VBA. But that can be easily defeated when someone just opens the database in Access and bypass all that custom code.

This is why some folks may use MDE as a tool to ensure that only actions are done via forms and never directly upon the tables, which MDE does nothing to prevent/stop, and there's no simple way of securing the table without utilizing the ULS because anything we do in code can be bypassed, whereas the ULS is part of the Access's codebase and thus effectively requiring one to reverse engineer Access to circumvent the ULS (but they don't even have to go that far- they can handily crack ULS by googling up for some tool to crack the password or .mdw files).

What exactly are you trying to accomplish? What are the threats you are trying to protect your data from?

basically, the forms, macros and modules are protected already by MDE format and passworded protected VB codes. thus, the tables are exposed, consequently the records are exposed. So my main concern is the table due to its records.

May I mention that I have created my own customized permission, however that does not include the table object to be protected. I dont mind much of the query object because I conclude that if the table objects are locked, the query object will also follow.

Banana, you said that we can wrap the objects with our own custom permission. So may I ask you how do you do that, regardless if that would be effective or not. I just wanna know how to make a code that would protect it.

does anyone knows how to achieve this solution? the code !

Here's one demo.

In general, locking the database implies that you don't trust your users. If that is so (and I know it happens), be aware that with Access, you are limited in what you can do. Not totally bereft of options, but limited.

I would implement some sort of logging, perhaps an audit trail of some kind. This forum has many threads for which you can search for articles. Look up "Audit Trail" and "Change Logging" as topics in your search. The Search option is on the ribbon menu near the top of the page.

Advise your boss of what you have done. Get the boss to agree that the database needs protection and that mucking with it would be considered very bad. Then if someone DARES to muck with the database, report them to the big boss who said this database required protection. Fear of unemployment in this economy should be a very powerful incentive.

Then, be sure your work gets backed up frequently. If you have another drive available, even if you use a network drive for production and your workstation drive for development, just be sure that the most current work exists in two places every so often. Three places would be better if possible.

As to users getting in through another copy of Access, that is what encryption is supposed to defeat. All of the stuff about blocking use of the various tricks to bypass the startup form and other ways to get into the database are important, don't get me wrong. Because then if someone breaks through all the muck'n'mire, they wanted to do something they shouldn't have done.

Work with your security manager to verify that you can see attempts to use the database in the file-server's Event logs or Application logs. Find out what you need to do and then DO it. You'll need that log ONLY if someone gets VERY determined to go into the database back-end despite all the warnings.

The best security tools are to educate your users as to WHY they aren't supposed to do certain things. And get the data owner to sign up with that notification. Then when someone perpetrates a breach, they can get anatomically rearranged (i.e. the boss can "rip someone a new one").

The idea is that you can never stop a determined user who really wants to bypass your security setup. But you can remove him from the playing field so he can't do it twice. And you can let the rest of the world know WHY that person is suddenly working the toilet-bowl detail.

Of course, in my office, since I work with the government, we add to that fate, "toilet bowl detail in Leavenworth, KS., and be sure to not drop the soap."

Banana thanks for the reply but the demo sample was not the one I needed. actually I have more or less same security design in my project.

What I wanted to know and have is a code that will lock the tables that it cannot be opened as a table object either in design or table mode.

Could you probably code that for me. I am not very much good in code.

That would have to be done via ULS.

As I wrote in my earlier post:

Short answer: No.

...

In order to implement our own encryption scheme, we would have to wrap every objects with our custom permissions. The only way to do this is to go through the VBA. But that can be easily defeated when someone just opens the database in Access and bypass all that custom code.

Click to expand...

We could programmatically manipulate ULS, but definitely not replace the ULS with our own custom code because as I said earlier, Jet is already designed to use ULS but if it's not used then Jet employs a 'don't ask, don't tell' policy WRT custom security codes and for that reason, I usually argue that custom security solutions are actually more vulnerable than ULS (when properly implemented!).

The custom code works as long as we open the database and allow the code to execution, but the game's over once they hold down the shift, automate the database or open it in a hex editor.


Furthermore, as The_Doc_Man alluded to, if you can't trust your users, it may not be as much as a software problem as a personnel problem in which the solution is best addressed by getting the boss or HR to cooperate with the policies and making any attempts to bypass the protection a cause for termination.

Finally, don't forget you also have the option of using Windows permission to keep out the nonusers entirely.

That said, one way to keep users from importing/opening the table outside of your application (and inside the application with code bypassed one way or other as well) would be to link the tables into a separate file and require a password for it. In one project I did, I prompted my users for a password which they would enter, and I'd hash it into something else and use *that* as password, meaning that even if they managed got to the data store, they didn't actually know the password because what they typed weren't what it was getting and thus denied access outside of the application. Since hashing can be done in code, and the application converted to MDE, they now have no way of getting to the algorithm used for hashing and figuring out how it worked. It's very important, of course, that you have salts to protect against rainbow table attacks or any other dictionary attacks as well form users guessing the hashing (there are sites where they can type in a word and get a hash).

Here's a good example of VB code for SHA-256 algorithm, which you can just drop in the VBA module.

Hi

here's a cheap trick that I recently used.

I forced my users to use the shortcut on the desktop and the shortcut had a cmd to run a macro. If the database was opened without the macro, I set an error trap to purposely error and in the trap, quit the application.

My front end is readonly so what happens is, the macro tries to create a record in a non existent table. If it is readonly, it bypasses as it can't create the record but if it isn't readonly, the attempt is made, an error occurs which triggers the handler and the app quits.

I then connect to my backend via pw protect to save any record changes. Then back end is not readonly.

Regs


Nigel

Nigel-

How do you protect from automation accessing the application?

ok. let say we could never replace ULS but we could progmatically manipulate ULS.

do we have the code to lock the object?

Using ULS, you mean? Something to do with Owner property and Permissions property for both Container object and Document object, which are documented in VBA help. I've not actually done this before and as I said before, it's probably best to use the Access's UI for ULS than doing it programmatically.

i think ULS employs coding to lock the object base on the user and permission set to it. so after access determines the related user and permission, it locks it with some kind of lock protection so as not to open it without the criteria. So what is that kind of lock protection? that is what I think. and that employs code. Do we know that code?

as stated on previous post that we can manipulate the ULS progmatically, therefore somehow we have an approach what is that code used by ULS to lock the objects. that what i think.

my reply to post #14.

yes! the code used by ULS to lock the object. I see that you have not done this before banana. thanks for that reply. yes probably in general that it is best to use the access UI but like for me, I wanna know how it is done programatically. thought some may be at ease using the ULS but not all are at ease using ULS. and for me who is searching for answer as my solution would really want to dig for help on this.

I am not an expert on VBA code Banana, so I rely to the expertise of the experts to help me dig this code for me to use on my project. I hope you can understand my situation as a novice. thank you very much.

As I said before, VBA help has some examples & information on the relevant properties.

The only one 'gotcha' I noticed was that to set permissions for a different username you would need to set the UserName property to that user first then you can set the permissions property, which is ummm, odd way of doing it. (I'd have expected permissions to be a collection within a collection of users for document/containers but that is not how it works).

I encourage you to read the VBA help files and learn all about the properties associated with the Containers and Documents objects and use the example as a base to build your code. This is truly a good way to learn how to code, and if you're stuck, we can help you through a specific question.

where do i find those vba help files for containers and documents objects? i think thats a lot of time for me to read. do you have any sample code for that matter?

In VBA Editor, in upper right, there's a textbox where you can type in a keyword and pull up a list of search result which you can then select from to read for more information. For starter, try "Container Object (DAO)". In the dialog that pops up explaining the object, there's also four links for Methods, Properties, See Also, and Examples. You can use Examples to see the code sample there.

I do encourage you to take the time to read them, as you will become much better coder once you learn how to get those resources and use it to build your code.

Here is the bottom line.

Access cannot give you the solution you want because it operates on a SMALL BUSINESS model. You can do better with Front End / Back End models where the back end is something like SQL Server or MySQL or something where you can actually implement a more strenuous security scheme.