>The only problem I'm facing (so far!) is to determine the best way to store (read "hide") the administrator's login and password. Better than that, if I could have a way that *only* the network administrators could set (or store) the login/password and the app could retrieve it for utilization.
>
>Some options that came up (and were discarded, maybe too soon <s>):
>- Hard code it inside the app source code
> - Store it in an .ini file
> - Store it in a field of a Dbf Table
> - Encript it and store it in...
>
It is back to the old and toughest problem in cryptography and security issues: Key management.
You could encrypt the password and store it in any of those places. Even in the Windows Registry if you want. But in order to decrypt you would have to have a key. That has to be kept someplace.
If you do not require a reversible pssword (i.e. that it can be decrypted and told to the user if they forget it), the you could use a one-way hash (like MD5). Keep it in any one of those places and when they enter the admin password, hash it and compare to the one stored within the system.
I'm not sure this will work for you as you want impersonation, where there is no admin physically present but the program (or actually a certain subroutine) has to re-login internally with admin privileges. The MD5 may not work in your case, as it could be conceivable 'copied' from the registry and plugged into a routine.
All depends onwhat level of se
curity do you need and you determine that by acertaining the level of attacks (attackers) you expect and the value of the data to protect.
For semi-secure situations the above issues may work.
BTW, 'impersonation' is not a new or Windows concept. It is very well known and understood in many other OS, going back to the SUID US Patent #4135240 "Protection of Data File Contents", January 16, 1979 by Dennis Ritchie.
