Hiding Tables

[Appollo14]

I have a client for whom i've written a large purchase order system. He's now growing as a company and wants to make his data more secure. At the moment the system uses linked tables which are hidden from the end user in the application, however, as the data is stored on a server once the link is made drive mapping occurs and the data is exposed.

What would be the simplest way to keep the users away from the raw data without totally re writing the app.

All suggestions welcome.

Regards,
Noel.

 

[lupins46]

You need to be more precise about what you are trying to prevent happening.

You could hide the backend file. You could put an autoexec procedure into the backend that closes it if it's opened.

But in the end you can't stop a knowledgable user running of with the a copy of the file.

 

[deekydoo]

HI,

I've got this problem. The only way is to put a vb6(or whatever) frontend on for the user. This will stop them gaining visual access to the tables.

Deek

 

[Appollo14]

Thanks for the reply Guys,

I had a feeling there would be no simple answe to this but was hoping to get away with not having to re-write the app - especially as i haven't done any work with VB proper!

Regards,
Noel.

 

[GingerR]

Even if you make a front-end if VB, users can still make their own blank db and import in or link to your data. Use MS Access Security. A bit to learn, but not that complicated once you do it. Then no users can see or link to any of your data.

As for users "seeing" your front-end forms, reports, code, etc...make an .mde file and then they at least can't see your code.

 

[deekydoo]

Hi Ginger ,

How can they see your tables if your VB is compiled? They couldn't see your code and the tables would only be visible to your code. I'm missing something here?

Deek.

 

[GingerR]

If you data resides in an unsecured Access database, people can make a blank database and link to or import your data.

 

[KornGeek]

Also, without using Access security, what is to stop a user from opening the back-end and telling it to display hidden files?

I agree with GingerR on the best approach here.

 

[deekydoo]

I see your point guys. Seems a lot of work but I guess it's necessary for security.
(Can I just put a password on the whole back end?)
Deek

 

[GingerR]

It's not that much work once you do it. First time is probably the hardest.

How would putting a password on the back end keep people from creating a blank db and importing your data?

 

[KornGeek]

Putting a password on an Access database is like putting a sign saying "Authorized Personnel Only" on a door, but not locking it. It will keep out those who stumble across it, but not anybody who is determined.

There are several utilities freely available on the internet that will display the password from an Access database. Not just crack it, but actually display it to you.

From what I understand, these started off as tools that hackers were selling, but were turned publicly available. This keeps the hackers from making money off of it, and also keeps people from relying on it.

 

[lupins46]

The front-end is almost irrelevant here, assuming you have some control over who sees what.

The issue you raised was access to the tables - and I assume from that your aim is to stop people pinching the data. As i have said you can take some precautions against this to prevent it being breached in situ but if a user knows where the back-end file is located they can just copy it and take it away or email it to themselves. Then, if they are determined enough, they have all the time in the world to crack it.
If this issue is critical to your user then they need to consider a server based back-end.

 

[jsteph]

You don't need a complete VB front end.

First, you should read the faq on JET security, but even without that, a few things can be done for a quick and dirty fix.

I've posted a more detailed solution in other posts, but in a nutshell (no pun intended...) you make a qucick and dirty VB.exe with a single line:

Shell("c:\progra...blah...MsAccess.exe" /wrkgrp "C:\winnt\system32...blah\secure.mdw"  /user 'someuser' /pwd 'somepwd' "C:\Somedb.mdb")

Obviously, you use variables for the paths, etc. You also trap keystate (use api GetAsyncKeyState) and nullify the Shift key. And of course in properties of the .mdb (or .mde) you diable special keys, menus, etc. Also my executable has quite a bit more stuff--ie checking Access version/path, etc.

Anyway, the gist is that the user clicks the vb executable, it shells Access with the secured .mdw and opens the app with db window hidden, no access to menu (except File|Exit), no view of dbwindow, etc.

It's really not that much work, and it adds that extra bit of security that the jet security model can't provide if you let the user just double-click on a front end .mdb
--J