Link to home
Create AccountLog in
Avatar of maximyshka
maximyshka

asked on

Protect tables in accde file, so no one can link in?

Hi,
I have the following problem. I have ms access addr file, which i create from mde file. TSo no one can access the code of application. Now if any one rename file back to accde then they can make link table to the database and see all tables from linked in database. Is there any way to protect tables or are there any settings which protects tables so no one can do linked in???

need help asap, i apreciate any help.

thanks
ASKER CERTIFIED SOLUTION
Avatar of DatabaseMX (Joe Anderson - Former Microsoft Access MVP)
DatabaseMX (Joe Anderson - Former Microsoft Access MVP)
Flag of United States of America image

Link to home
membership
Create a free account to see this answer
Signing up is free and takes 30 seconds. No credit card required.
See answer
Avatar of maximyshka
maximyshka

ASKER

but then same password needs to be used for accdr...  it doesn't solve the problem. gotta be some methods
"but then same password needs to be used for accdr..."
Why is that a problem.  And there is basically no difference between accde and accdr in this respect.

The only other thing you can do is try and mess with Windows folder permissions, but I have yet to see a simple, foolproof way to do this ...

mx
I wrote my own authentication system in application which handles user access based on their credentials. So giving all of themm same password will not solve anything, there is gotta be better way.  On file start i worte a code that if file not accdr then it it closes files automaticly., but now some users rename file and do linked tables to data and play with it... Yesterday i saw application which protects tables somehow... but i don''t know how they did it.
<<Is there any way to protect tables or are there any settings which protects tables so no one can do linked in???>>

  Short answer is no.  Since the ACE format no longer honors ULS (User Level Security), there is no way to prvent linking to your tables any more (and for what it's worth, ULS was breakable anyway).

JimD.
This id one of the major security issue with us8ibng an Access back end.  It is nothing new,. This has always been an issue. using Microsoft's  SQL Server as the back end with NT Authentication is the best solution I know.

You might also want to see this:  UtterAccess.com thread Access 2007 security
and vPPC Security Toolkit (VST)
 
So ... as I noted, other than a password OR possibly messing with folder permissions ... there really are no other options.

mx
Ideas to try:
1. split your database into FE/BE configuration, moving the address data into the BE database.  Encrypt the BE database.

2. Keep the BE database in a TrueCrypt file.  As part of the FE start-up, mount the TC volume and restrict permissions to the volume to the current user.  Dismount the TC volume during FE database shutdown.
 
" Encrypt the BE database."
How ?

mx
Hopefully, you'll find this helpful
http://office.microsoft.com/en-us/access-help/hide-vba-code-from-users-HA010239557.aspx#BM4

Generally, you open the database exclusively and use the Database Tools | Encrypt with Password menu

LSMConsulting suggested a database password in this question
https://www.experts-exchange.com/questions/25193938/Locking-down-an-Access-2007-ACCDE-Database-objects-Tables-Queries-Data.html
Well, unfortunately if you are talking about the built in Access encryption, that does not really do what you might think.  Nothing to do with scrambling data in tables.  All it does is 'encrypt' the db internally, such that if you open the db with Word or Ultra Edit (et.al.), it makes it more unreadable that it already is.

mx

The issue is not in the back end or even encrypting the back end. This does not protect the front ends linked tables.

I can easily attack the front end and gain full access to an encrypted (password protected)  back end.

If you are going to use an ACE/JET back end then the best solution I have ever seen is the vPPC I linked to previously. To fully understand the security issues that maximyshka is wanting solved please read the discussion I linked to in post http:#35765175 .
I've requested that this question be deleted for the following reason:

This question has been classified as abandoned and is closed as part of the Cleanup Program. See the recommendation for more details.
I think the question has been answered, which is "You really can't do it"

mx
I agree that this has been answered. Unfortunately the correct answer is not what Dhaest was expecting or wanting to hear..
Sorry guys I had to leave for unexpected paternity leave. This question wasn't answered. I found a solution wich is : I have a file with no tables attached. when user enters user name and password on the form i link table and check if user name and password match. If they match I link all tables, and delete users table so it will not be exposed. if user does not exist or password is wrong no tables linked. On the exit i delete all tables.... This way the file is always empty .... Fortunately VBA code is protected by  accde file
@maximyshka

Please accept your comment http:#36003170 as the solution.
I've requested that this question be closed as follows:

Accepted answer: 0 points for maximyshka's comment http:/Q_27039417.html#36003170

for the following reason:

Although some good ideas were discussed, but none of them provided a full solution to the problem. I found a complete solution myself and posted it for others to see.
maximyshka:

<I found a complete solution myself and posted it for others to see.>
Well ... Your solution is not a solution at all. It can easily be circumvented.

<<... delete users table so it will not be exposed>>
Well ... it is exposed until you delete it.

<<If they match I link all tables, and delete users table so it will not be exposed. if user does not exist or password is wrong no tables linked.>>

<<On the exit i delete all tables.... This way the file is always empty >>
What if Access is forced to "crashed" then the linked are left in place and can be retrieved.

Unless you left out some of the step your  posted solution is not secure.

Boyd Trimmell aka HiTechCoach
Microsft MVP - Access Expert

That really does not protect anything. The problem is that as soon as you create the table they can be compromised.  So you have only might is slightly harder.