I'd be interested in this too
Although I've implemented my own now, I am interested in seeing what suggestions crop up.
As for your idea of storing DSN/userid/password in a text file, even with encryption, I doubt it will be as secure as making the user remember a password. If you are saying that you have single login for multiple users in this app/DB and yet you say you are in a high-security institution, then I guess I am somewhat dumbfounded.
Assuming then that I read you wrong, you could use the user's userid/password to act as an encryption key for the rest of the data. If the DSN is secret and shouldn't be passed out to anyone in your institution (again, quite strange to me unless you expect internal hackers I suppose) then the DSN can be encrypted.
Personally, my suggestions are:
1) individual login for DB access (your administrators can't argue with that surely!)
2) Store the DSN in an ini file - no need to encrypt it
3) Store the last userid in the ini file too if you like
4) In the login screen, populate a combo with the list of DSN's to choose from, make the user type their name or populate it from the last userid info from the ini file, then make the user type their password.
This means that the DB will control the access rights of the user, and you don't need to worry about a weak encryption system in your app.
But if your heart is set on encrypting something, usually you will want an encryption key that is not hard coded so as to avoid the possibility of someone cracking their own encrypted login info, then using that key to crack everyone elses.
Post or email me if you want more info, otherwise I hope you get the answers you were looking for from our fellow programmers :)
Cheers
I think I was not 100% clear
The encryption of login info is only applicable to the actual ODBC login. Now I do NOT expect there to be a serious problem from internal hackers. I only suggested the encryption as a way to make sure that the odbc login was not EASILY visible. To make it a bit clearer, there are 2 logins that occurr. The first ODBC login, and then asecond user specific login. (I am only finishing what someone else started... yes.. I know this is a dumb way to do it).
I guess My MAIN question was regarding how specifically I manipulate a text file to store the last used ODBC info. the reference boks I have seem to gloss over the area of actually using a text (or INI) file to store the data. Encryption really is optional. Adding it would basically insure that it took a deliberate attempt to access the ODBC info by someone internally. The network is in no manner shape or form connected to the internet, so outside tampering is a non-issue).