> there is no excuse for a plaintext passsword in an .ini > file period
There is one instance where this becomes questionable, and that it during automatic bootstrapping of daemons/services. I did not say desirable, just questionable ;) Many programs need a private key for encryption. Possession of this key is usually part if not all of the decision for authentication. The only relatively safe way of maintaining this key on disk is to encrypt it and require a decryption password from the user when starting the process. Unfortunately, system admins have a beef with servers that restart and require an operator to input a password to get the services up, especially in production environments. This leads many to some level of 'plain' storage and trust in the OS ability to lock down file access. You can obfuscate the information to up the ante a tiny bit, but you are ultimately relying on the OS to protect you. Of course, none of this applies to IRCX. I just wanted to point out the situation I have seen where theory and practice don't always agree. -- David _______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
