Super Simple Question on Properties

[Kevin Seitz]

Super simple (or is it?)

I want to store information as userdefined properties in the database
properties window....

currentdb.containers("databases")!userdefined.properties!...

If i make my database an MDE, disable the bypass key, remove "Database
Properties" from the file menu, remove the database window, and have a
startup form, is there anyway the user could change that information other
than having Visual Basic code in the program change them?

If I could prevent the user from changing them, please tell how.

Thanks in advance

 

[TC]

If the property was created with the 4th(?) (DDL) parameter of the
CreateProperty procedure False, >any user< can change the property. If it
was created with that parameter True, only members of the Admins group can
change the property.

In either case, the code in question can be run from a new database that the
user creates himself. (It need not be run from within the MDE database.)

HTH,
TC

 

[TC]

Even values that you write to the registry, will be easily visible using
publically available tools (eg. sysinternals regmon).

I recommend that you proceed on the following basis. 1% of effort will deter
99% of users. >NO< further effort - no matter how large - will deter the
other 1% of users. They will disassemble your code, if needs be, to defaut
your security. In a desktop PC environment, there is really nothing that you
can do to stop this.

So I would stay with the database property. But:

o >encrypt< the value with a simple scheme of some kind. For example, if
you are storing the expiry date, store %##@%^&* (or whatever) instead of
"2/2/2004". Thta will stop the people who know just enough to be able to
look at the database properties.

o >checksum< the value. Then, you will know if anyone has tried to change
it (just to see what happens).

Of course, this will not stop a "replay" attack, where the user saves the
initial value of your database property, runs your app until it expires;
then restores the original (saved) value of the property. In some schems,
that would get him another 'x' days. You can stop such attacks by adding
vcertain further checks - but it's just not worth it, IMO. You are now
trying to defeat the 1% of users whom you will >never<, in fact, be able to
defeat at all.

HTH,
TC

 

[Kevin Seitz]

Well, is there any other way to securely store data without using user-level
security? I would use a table but that can be linked/imported and edit by a
user.

I guess what I am mainly trying to do is set a trial version for a program
so that the user can use it for so long and then has to register. I found a
solution to this at http://www.logico-solutions.com/ . However, I am
deploying the database where installers aren't exactly good and probably
don't have references to all the codes I need.

Is there any way I could possibly write the values to a DLL or the registry
myself? Tell me if there is (a link to a site works good too) ANYTHING THAT
IS PARTIALLY SECURE WOULD WORK!!!! THANKYOU
kevin

 

[Kevin Seitz]

Ok so lets just say I store those date values into the properties (since
most users won't have a clue about the name or what it does 99%) and I come
up with a encryption scheme (like 12/17/03 stored as %^&#&%*) how I can I
pick apart the
date and match it to the encryption? Let me make sure what I want.....

EXAMPLE:

0 = Z
1 = A
2 = B
3 = C
4 = D
and so on....

So if I stored the expiration date as AB/AG/BZZC.... how can I get it to
switch over to 12/17/2003 on demand? I think I'm looking for how to match
every character to its encryption key value and put it in a new, hidden
temporary field for use. So how would I pull out 1 character at a time? Hope
this makes sense.

Thanks for all the help.

 

[TC]

Do something really simple. For example, I think there is a parameter to the
Format() function that will return a date as a so-called Julian number. Use
that method to convert the date to a number, then convert the number to a
string (Str() function), and store that string in the property.

Do not call the property: "CutoffDateAsJulianValue"! Call it:
"AppBuildNumber", or something similarly misleading.

To get the date back (ie. decrypt it), retrieve the string value, convert it
back to a number (Val() function), then use DateVal(?) or some other
appropriate date function to convert the Julian number back to an actual
date.

Sorry I can't give you actual code, but I don't have Access on this PC.

These are >very simple techniques<, they rely on the dreaded "security by
obscurity", and they could easily be broken by a determined person. But they
are easy to code, & they would certainly deter the 99% of people who can be
deterred with 1% of effort.

Understand that I am not trying to promote home-grown security schemes, in
general. These are seldom worth the effort, and they often have big holes in
them! I am simply answering your question of how to store a lightly
encrypted date value, in a database property.

Cheers,
TC