As my server is getting a bit bigger, and more users are getting access to it, I don't want them to see the password that MySQL is using to connect to PHP, which is stored in my 'connect.php' file and required by every page. However, it is just sitting in the same directory as the rest of the php files.

I've considered using a second 'connect.php'-like file with access to only one table, that stores the encrypted passwords to connect to MySQL, but then I would have the problem of hiding the key to it.

Changing permissions won't work either, if you chmod o-r or something similar, nobody will be able to access the web application, obviously.

Is there an accepted method to get around this problem, or should I just solve it on my own? The problem is that I don't want it to be too convoluted if there is an accepted method.

All the answers have good advice but fail to address the fact that any user with server access can just snoop around and open the config.php in an editor.

Set your config files in a directory outside of public webspace , the webserver should be the owner of this directory and it should have permissions set to 700. All files it contains should be 644. This way no one can even read the file contents apart from webserver user or root.

This is a common approach, but there is a lot more to the subject as security is a very vast topic, but is better than 90% of the setups out there.

I have a ASP.Net C# application that needs to connect to an external API using WebServices every 5 minutes.

The requirements of the External Webservice are as follows:

• Username and Password are required
• I must transmit the username and password with each webservice request
• Passwords expire every 90 days and must be changed prior to the expiration date
• Passwords cannot be changed manually (by human), my application must connect to a separate Password Change Webservice to change the password.
• My application must generate each new password based on a set of rules.
• Passwords can never be reused.
• SSL, Certificates and Firewall IP restrictions are required

I have built all of the previous, but I currently have one issue. What is the best practice for storing the current and historical passwords?

Obviously storing the plaintext password is a bad solution. I need to be able to have my webservice read the password and transmit it with each request. I also need to be able to access all of the historical passwords to make sure that my newly generated password is not a duplicate.

Ideally, I would like to store each (encrypted) password in my database and decrypt it whenever I need to call the webservice. Is there a best practice I should be following? Should I encrypt each password using Microsoft.Practices.EnterpriseLibrary.Security.Cryptography.Cryptographer.EncryptSymmetric(..)?

Note: Unfortunately, I have no access to change the way the external API functions. I must follow the rules provided.

With regard to the password history I would go down one of two routes:

1. As per your current plan, store passwords in file/db/config - suggest you use a hashing algorithm (as opposed to encryption) to compare the new password with stored password hashes for "equality".

2. Don't bother storing password history at all - let the first attempt to the password change web service just fail if it chooses too, then resend with an alternative password. This way, you are not duplicating the business rules of the password change web service (for example, lets say they change it to allow you to re-use a password after 6 months time).

With regard to storing the current password: assuming you must send the password as plaintext, then yes, you should store it in encrypted form. There are many articles out there on how to do this. Or you could even encrypt a specific section of your config file such as seen here.