I have spent some time going through the information on securing an Access 2k database along with using the Security wizard. I have come to some conclusions, the security schemes are not straight forward and #$%!. Sorry for the venting. What I am trying to do is as follows. I have a database with two main tables along with 4 lookup tables. The lookup tables are used in calulating values for answers of certain questions and then the questions are grouped according to their values. I have two main forms that are used to store the information in the tables. I do not want the lookup tables to be viewed by the user, but since my input forms use the lookup tables for computations I cannot lock them form being viewed. Must I put these lookup tables in Visual Basic behind the form that is using them? This poses a problem since they will be changed periodically and they where originally generated from an Excel spreadsheet. Should I use a scheme of hiding them from view and then disable the menus along with disabling the shift key on loading the database? Will this work to keep unwanted eyes from peering at the data? Any views or advice on this subject is greatly apreciated.
Security Planning (1 Viewer)
- Thread starter Smev
- Start date
- Local time
- Today, 05:12
- Joined
- Feb 28, 2001
- Messages
- 27,229
The solution to this problem: Look in the help files for queries that have the attribute set to Use Owner Rights (as opposed to using user rights.) Also search this forum for that topic.
Now, another part of this is that you must prevent users from seeing the queries. Do you take steps to hide the database window ?
In essense, yes.
Thanks, for the quick reply.
I am finding that the security scheme of this product is not useful for the product that I am building or I am missing something.
We will distribute this database to customers after a work session with them. It will provide recommendations based on how they answers the questions within a form. Visual Basic behind the form calculates the recommendations based on the answers and values from lookup tables. How in my right mind can I give them something that has a shortcut based on the directory paths on my computer. I must tell them to put the database in the same path on their computer or walk them through changing the path of the shortcut. Who came up with this security scheme anyway? Why can't it just be a straight forward password with rights or permissions given to the object within the database? I am begining to think it may be easier to just have two database, one for the customer on one for us. Any more views on this subject will be appreciated. There must be a sensible way to provide security on this database. I would probable be better off writing the whole thing in C++. vent,vent,vent,vent,vent!!!!!!!!!
I am finding that the security scheme of this product is not useful for the product that I am building or I am missing something.
We will distribute this database to customers after a work session with them. It will provide recommendations based on how they answers the questions within a form. Visual Basic behind the form calculates the recommendations based on the answers and values from lookup tables. How in my right mind can I give them something that has a shortcut based on the directory paths on my computer. I must tell them to put the database in the same path on their computer or walk them through changing the path of the shortcut. Who came up with this security scheme anyway? Why can't it just be a straight forward password with rights or permissions given to the object within the database? I am begining to think it may be easier to just have two database, one for the customer on one for us. Any more views on this subject will be appreciated. There must be a sensible way to provide security on this database. I would probable be better off writing the whole thing in C++. vent,vent,vent,vent,vent!!!!!!!!!
Oldsoftboss
AWF VIP
- Local time
- Today, 20:12
- Joined
- Oct 28, 2001
- Messages
- 2,499
Are your customers Access literate. If not (and there is no reason they should be) there are several simple thing that you can do to add 'basic' security.
1.. Under tools - startup you can hide the database window, Disable the F11 option (Access special keys) and nominate which form opens when the database is opened.
2.. if this is not what you want you can right click on a table in the database window and select properties and then check the 'hidden' box. This hides the table but can be seen by selecting hidden objects under tools - options - view
3.. Disable the shift key start up option. (Remember to have a way of re-enabling it) There are many posts on this subject
HTH
Dave
1.. Under tools - startup you can hide the database window, Disable the F11 option (Access special keys) and nominate which form opens when the database is opened.
2.. if this is not what you want you can right click on a table in the database window and select properties and then check the 'hidden' box. This hides the table but can be seen by selecting hidden objects under tools - options - view
3.. Disable the shift key start up option. (Remember to have a way of re-enabling it) There are many posts on this subject
HTH
Dave
Oldsoftboss, yes I have looked at or tried all that you suggest. I have a problem with your comment "Are your customers Access literate". Anybody with some computer knowledge, a little time and the "love of the challenge" will figure this out within a few minutes. Our customers are large corporations and will have many people with the skills to figure this out.
What I would like to do is combine your suggestion with the security options within Access, my problem is the stupid shortcut that is built to run the security file '.wdw'. The shortcut solution is a lame solution since it is based on a path on a certain computer (am I wrong here?). A short term solution is to provide an 'mde' file, but that will not allow us to update certain parts of the database that we do not want the customer to update (I believe at this time?). I suppose I could write background code to accept user names and passwords and then open forms based on those user names. Has anyone tried this? Does anyone from Microsoft read this forum? Maybe I am missing something but the security schemes used on Access are very poor at best. Looking for more opinion on this subject!
What I would like to do is combine your suggestion with the security options within Access, my problem is the stupid shortcut that is built to run the security file '.wdw'. The shortcut solution is a lame solution since it is based on a path on a certain computer (am I wrong here?). A short term solution is to provide an 'mde' file, but that will not allow us to update certain parts of the database that we do not want the customer to update (I believe at this time?). I suppose I could write background code to accept user names and passwords and then open forms based on those user names. Has anyone tried this? Does anyone from Microsoft read this forum? Maybe I am missing something but the security schemes used on Access are very poor at best. Looking for more opinion on this subject!
Oldsoftboss, ok I thought about this a little more. If I hide all objects and lock out the shift key by a password, then a user cannot see the objects to import into another database? Is there anyway around this? I mean is there someway a user can see these objects if they cannot get to the menu bar? If the objects are set to hidden is there a way to copy these into another database? I believe I know the answers but would like conformation from another source (higher ofcourse).
Oldsoftboss
AWF VIP
- Local time
- Today, 20:12
- Joined
- Oct 28, 2001
- Messages
- 2,499
If you are refering to me as a 'higher source' then you are sadly mistaken
I found that if you paasword protect the code in the VB editor then your forms (at least) cant be exported.
Any other views on this subject ?
Dave
I found that if you paasword protect the code in the VB editor then your forms (at least) cant be exported.
Any other views on this subject ?
Dave
oldsofty
I have proceeded with an approach of using the function to turn off the "shift key" on program load, hidding objects and disableing the menus. Along with this I have implemented a form to input a user name and password to control the "shift key" and set a bit to display some of the controls on my forms. I am close to having this done.
Question?
Can I store a value within Visual Basic code that can be changed at run time but the state is stored upon closing the database and when it is open the same state that was stored can be read?
Does this make sense? I don't want to store it in a record of a table. I will look through the forums on this subject.
I find that this solution will work for a solution were I am sending this database to customers. The place of a 'shortcut' on a customers computer just does not seem right for this application.
I have proceeded with an approach of using the function to turn off the "shift key" on program load, hidding objects and disableing the menus. Along with this I have implemented a form to input a user name and password to control the "shift key" and set a bit to display some of the controls on my forms. I am close to having this done.
Question?
Can I store a value within Visual Basic code that can be changed at run time but the state is stored upon closing the database and when it is open the same state that was stored can be read?
Does this make sense? I don't want to store it in a record of a table. I will look through the forums on this subject.
I find that this solution will work for a solution were I am sending this database to customers. The place of a 'shortcut' on a customers computer just does not seem right for this application.
Oldsoftboss
AWF VIP
- Local time
- Today, 20:12
- Joined
- Oct 28, 2001
- Messages
- 2,499
You can't store a value in VB to still be there next time you start access. Also you dont need to disable the shift key each time you load the program. Remember, once you have started access, the shift key bypass is then too late. Refer to the many posts by ghugston on the code he uses to enable/ disable the shift key.
I have made my own log on screen that when a user logs on it reads the access level from a table and starts accordingly. The only problem I foresee with what I'm doing is that this table may be able to be imported into another database. If you set the format in the table to password, this stops the field being copied and pasted even if they get to see the table with the *****'s in the password field.
I have made my own log on screen that when a user logs on it reads the access level from a table and starts accordingly. The only problem I foresee with what I'm doing is that this table may be able to be imported into another database. If you set the format in the table to password, this stops the field being copied and pasted even if they get to see the table with the *****'s in the password field.
MikeAngelastro
Registered User.
- Local time
- Today, 04:12
- Joined
- Mar 3, 2000
- Messages
- 254
You might encrypt the data in the lookup table and then decrypt it when you pull it out to make the calculations. The key will be in the code which will be unreadable when compiled to an mde. The data in the table will also be unreadable to prying eyes. You will probably have to add an cipher class to the app in order to do this. Or maybe you can write symple code to do the encryptio yourself.
ok, if you are still interested. This is what I have done so far.
1. Made a logon screen to set the code that locks out the shift key.
2. Hid all the objects and turn off show hidden obljects in the menu.
3. Passworded my Visual Basic code.
4. Made an MDE file.
5. Encrypted the MDE file.
Some observations and questions.
1. With MSQuery I can see the hidden files and can read in the data if it is not encrypted. This really bothers me, if they are hidden they should be hidden from all MS products atleast. When it is encrypted there is a syntax error. This is fine but how do I stop some one form decrypting the file. It never asks for a password when you encrypt it.
2. With MSaccess I do not see the hidden files if I try to open a new database and get external data. This is what should happen with MSQuery.
3. Since MSExcel uses MSquery the data can be read from my database if it is not encrypted.
4. Encrypting my mde file made a MDB out of it. Is this how it is supposed to work?
Can anyone explain the encryption process and how to ensure it stays that way unless I decrypt it?
Mike, I am not sure how to encrypt the data in a table.
1. Made a logon screen to set the code that locks out the shift key.
2. Hid all the objects and turn off show hidden obljects in the menu.
3. Passworded my Visual Basic code.
4. Made an MDE file.
5. Encrypted the MDE file.
Some observations and questions.
1. With MSQuery I can see the hidden files and can read in the data if it is not encrypted. This really bothers me, if they are hidden they should be hidden from all MS products atleast. When it is encrypted there is a syntax error. This is fine but how do I stop some one form decrypting the file. It never asks for a password when you encrypt it.
2. With MSaccess I do not see the hidden files if I try to open a new database and get external data. This is what should happen with MSQuery.
3. Since MSExcel uses MSquery the data can be read from my database if it is not encrypted.
4. Encrypting my mde file made a MDB out of it. Is this how it is supposed to work?
Can anyone explain the encryption process and how to ensure it stays that way unless I decrypt it?
Mike, I am not sure how to encrypt the data in a table.
MikeAngelastro
Registered User.
- Local time
- Today, 04:12
- Joined
- Mar 3, 2000
- Messages
- 254
Smev,
Do you have VB 6? If you do I can send a simple loggin program I created just to play with encryption. I did it because I had read somewhere that it was difficult to reliably secure a loggin for SQL Server because someone using Query Analyzer could still read the loggins and passwords.
My program stores the security info in either an Access DB or in SQL Server itself. It not only is able to add users in groups but it also decrypts the data when it pulls it out of the table. Also because the data is stored in the table encrypted nobody will be able to make any sense of it. Also even though I use the same cipher class, I use a different key for the userid, group, and password. So a spy would have to figure out all three keys.
If you don't have VB 6, I can send you the class and you can try to play with it in Access. Let me know.
Mike
Do you have VB 6? If you do I can send a simple loggin program I created just to play with encryption. I did it because I had read somewhere that it was difficult to reliably secure a loggin for SQL Server because someone using Query Analyzer could still read the loggins and passwords.
My program stores the security info in either an Access DB or in SQL Server itself. It not only is able to add users in groups but it also decrypts the data when it pulls it out of the table. Also because the data is stored in the table encrypted nobody will be able to make any sense of it. Also even though I use the same cipher class, I use a different key for the userid, group, and password. So a spy would have to figure out all three keys.
If you don't have VB 6, I can send you the class and you can try to play with it in Access. Let me know.
Mike
Mike, I do have VB6 and would appreciate the code.
Do you have a suggestion on a good source book to learn encryption technics? I would like to try your suggestion of encrypting the lookup tables. Would this just me a matter of reading the record data jumbling it up and putting it back in the same reccord?
Do you have a suggestion on a good source book to learn encryption technics? I would like to try your suggestion of encrypting the lookup tables. Would this just me a matter of reading the record data jumbling it up and putting it back in the same reccord?
MikeAngelastro
Registered User.
- Local time
- Today, 04:12
- Joined
- Mar 3, 2000
- Messages
- 254
Smev,
Send me your email address and I will send you the code.
Mike
Send me your email address and I will send you the code.
Mike
