Accessing Tables with Shift Key disabled

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

Have a form based Access 2003 database with Shift key disabled. However, two
settings I do not want users to change are stored in a database table. How
easy is it for a user to gain access to this table without going to the
trouble of buying/using a hack programme?
 
milest said:
Have a form based Access 2003 database with Shift key disabled.
However, two settings I do not want users to change are stored in a
database table. How easy is it for a user to gain access to this
table without going to the trouble of buying/using a hack programme?
Click to expand...

If all you have done is disable shift it would take virtually nothing to get at
the table. All they have to do is create a new file and link to or import the
table from your file.

You could hide it which would require that they know how to adjust their options
to show hidden objects. You could prefix the name with "Usys" and that would
require that they change their options to show system objects. You could place
that table in another file stored in an obscure location with an obscure name
and only pull the data from it in your app in code (don't create an actual
link).

Other than these and other obfuscation techniques you would have to utilize the
User Level Security available in Access. While that can be hacked it does
require that they obtain a utility for doing so.
 
Thank you; interesting thoughts and your first point alarmed me as I didn't
realise it was that simple!! Will look into other points you made.
 
There is a way to do it (without using Access security) if you make
your database into an MDE, so that the users can not see or change your
code.

Say the value that you want to protect, is 999. Don't store 999.
Instead, store:

encrypt(999 & checksum(999))

where checksum() returns a checksum of the specified value, and
encrypt() encrypts the specified value in some reversible manner.

Then, when your code needs to retrieve the controlled value:

- get the value from the table;
- decrypt it;
- validate the checksum.

By that means, the user can see something in the table, but the value
does not make sense to him (because it has been encrypted), /and/, he
can not change it (because the checksum will then be incorrect).

Rough - but often effective. However, you do need to understand the
basics of encryption, and checksumming, before you could do this.

HTH,
TC
 
This is very helpful but I am guilty of failing to tell the whole story. I
need to be able to change these values (or rather I wish users to be able to,
if they have paid extra) and I have then supplied them with a 'code'; in
other words the database they originally bought is to beupgradeable. However
I do not wish each supplied version of the database to have to be uniquely
different as this would be too hard to implement.

Will try to learn about encryption and checksums to understand it more and
see whether I can develop what you suggest. Many thanks again.
 
Back
Top