Custom login

voiD

Registered User.
Local time
Today, 01:50
Joined
Sep 9, 2005
Messages
37
Hello,

I use to write small apps in Access for multiuser enviroment and I am not satisfied with the native security possibilities of Access. I got lots of trouble with shared .mdws and such things. That's why I've decided to make my own login procedure.

BUT, to make it, I have to store user names and pws in a table in the db. I want to make a secure db, but if I store these data in a table and somebody starts the app with pressed down shift key, can see the tables and their contents, e.g passwords and then where is the security?

Does anybody have idea in connection with it? :confused:

Thanks in advance for tips and help!

VoiD
 
Hello:

You can hide the tables. Just preface the name with

Usys
 
Thanks for the fast reply!

It seems to be a good idea, but my problem is with it, that if somebody knows how to 'cancel' program running with shift key, presumably will know how to see the hidden or sys tables.
The db structure is fe/be. I thougth what if I attach from vb code every time tables from be when program starts and I detach them on exit. I assume, it makes the start and the exit of the program much slower than in 'normal' cases.

VoiD
 
You can do this to unhide the tables
options1.png
 
You don't have to preface a table name with "Usys" to hide it. Just right click the table, go to properties, and check the "hidden" attribute.
 
Thank you very much Moniker for the help!
It is a good stuff, but doesn't solve the problem totally. The passwords can not be seen, but what about other fields and tables? My aim is to protect every data against unauthorized access or view without using Access' native security solution. I assume it would be a bit hard to 'hide' every field's content in the db on this way. :)
I am writing my solution for this problem, I am going to publish it here when it is ready.
Thank you very much again for the help!

VoiD
 
if you are using an mde, you can have a couple of procedures to encrypt/decrypt passwords etc, then users can see the data files without knowing how the encryption works

for general use, i would think any simple cipher would be OK.
 
The best you could do would be to put all your tables and queries in a separate DB and use links to get to it. Password protect the DB with all your tables and queries in it. If they don't know the password to that DB, there's no getting to the underlying data. The problem is, of course, you have to manually reestablish the links in code. You can hide the password value using Hexadecimal and/or Octal values, as in:

txtPassword = CHR(&H47) & CHR(&H55) & CHR(&H45) & CHR(&H53) & CHR(&H53) & CHR(&H4D) & CHR(&H45)

(That sets the password to "GUESSME", btw.)

Personally, I think you're being rather paranoid, but you know your users better than I. :)
 
Last edited:
The best you could do would be to put all your tables and queries in a separate DB and use links to get to it. Password protect the DB with all your tables and queries in it. If they don't know the password to that DB, there's no getting to the underlying data.

Just something to be ware of - Putting a password on an Access database is not very secure anyway. It will keep out the casual user, but it won't keep out someone who knows what they are doing. I ran into a free product named Db Password Sleuth which will give you the password to any Access database with a simple Access password.
 
Moniker, thanks for the idea, but I think, I've found out what I am going to do. My be is an ms sql db and the fe connects to it via odbc. There is one login for the db on the sql server and that's all. When the fe starts a procedure attaches all neccessary tables, using the login created on server and when the program finishes an other procedure detaches the tables. While the program is running, tables can not be accessed directly, only by the program, i.e. users can access only those data and only on that way what I allow to them. ;)
I know it is a bit time consuming, but currently that is the best what came into my mind.

Regards,

VoiD
 

Users who are viewing this thread

Back
Top Bottom