Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations SkipVought on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Security feature

Status
Not open for further replies.

cdjconsulting

Technical User
Jan 10, 2001
6
0
0
US
I have a database that is operated from a form called "main menu." I'd like to keep people out of the access portion (only have access to the main menu and sub-forms, etc.) and then have the main menu inaccessible after 30 days. I have zero VB skills - basically self taught up to this point.
 
You can compile and make an MDE. Make sure your Mainform is your startup from. There are many other threads on this particular subject. You may want to try a FAQ or a key word search for that subject.

In brief, an MDE is like an EXE, but not. An MDE protects your source code and "under the hood" items from the curiosity of users.
 
Got through the MDE step. Thanks! Any thoughts on the "make the app unusable after 30 days" feature?
 
In the most general sense, I do this by having the installation process create a registy key. the key name is selected to be somewhat obscure and the key valus is the installation date (encrypted). When the App is started, it checks for the key. If it is not found, it creates it and fills in the value. It it is found, it decrypts it and compares it to the current date - 1 month. If the installation date is > the current date - 1 month - exit, else go ahead an run.

It is simplistic. It can be 'broken'. It will keep honest john from a life of crime. It will not slow down a determined hacker enough to even waste the time to do it redundantly. Variations on the theme are more or less endless.


MichaelRed
redmsp@erols.com

There is never time to do it right but there is always time to do it over
 
Yikes!

TO: Michael,

I realize your suggestion is a good one and quite common, but what exactly are the risks? In other words, are you suggesting that he pick a key at random to create it from? What key do you recommend user's utilize for this purpose?

Also, wouldn't a small table internal to the MDE be sufficient for doing the same thing as well?

Gary
gwinn7
 
gwinn7,

Is that your age? Quite precousous(sp?).

Oh - well. to the question(s).

If you maintain an internal table within the MDE, you need some way to 're-write' the MDE file the information so that the changes are retained. This CAN be done, but it is somewhat involved and my opinion is that anyone asking this question is not quite ready for this level of convoluted thinking or the level of programming.

I don't think a random key would work for much the same reasoning as above. If you create a random key, you will need to also keep track of it's random-ness. this goes back to the above.

What I meant was to pick a key whose name and location would be rather obscure and certainly NOT related to the app name in any way. This is just to keep honest john honest. Place some value in this key. Almost any simple encryption process will keep the casual user from seeing it's value, and that is more or less all i'm attempting to do, keep the 'secrete' from prying eyes.

As an example, let's say the app was "MyUserDb.MDE". I might create a Key "HKEY_LOCAL_MACHINE\Software\BTRieve\TrashCollector" and assign its a value Of DateAdd("m", 1, Date) - encrypted with my own name (or just Acme Construction Company Inc.) It makes little difference, since the construction of the key and the value are hidden within the MDE program.

The 'risk' is only that someone has the desire and patience to be a real thief. He/she will be able to get through this scheme in less than five minutes. (although I will not describe the process) Once the code is 'broken' all the thief need to do is just wipe out the key every month. Dum-Dum the program will just look fior the key, not find it and hapily re-create it.



MichaelRed
redmsp@erols.com

There is never time to do it right but there is always time to do it over
 
Michael,

All I was asking was for you to elaborate on original response and I appreciate that. Your arrogance is irrelevant and unnecessary to this forum.

I asked you to expand on the registry concept because I wanted the user to know (as well as I) which areas in the registry would be good places to insert these keys. It is well documented that the registry is a VERY sensitive area of the operating system. To some people of less experience, your explanation helps.

You have my thanks,
Gary
gwinn7



 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top