This question is generally similar to past questions asked here, but I haven't seen one the relates to Linux.

Case at hand: a PHP web app has a MySQL backend. As part of its functionality it accesses other, remote MySQL hosts and issues some queries on those hosts.

To allow that, the PHP app needs credentials for those remote databases. What is a reasonable way for it to store/fetch such credentials?

It is required that the users of the app do not provide such credentials themselves. Also, there could be dozens of users to this app.

All users of the app are identified via LDAP. The app and the entire set of MySQL servers lie within the same internal network (requires two step VPN verification). The entire setup runs on Linux machines.

What are reasonable solutions to this problem?

  • keep them in a regular database, in md5 format or something similar. Once they logged in, give them a session which would enable them to reach to remote databases? No session-no access. And you can set roles to users to determine who can access what...
    – cengizUzun
    Jan 13 '14 at 18:23
  • I don't have a problem with sessions and roles. But how would I store the remote DB credentials? I cannot do that with MD5 since I need to be able to get the cleartext. Jan 13 '14 at 19:05
  • Do the users need to access the remote database with their own credentials? You could store credentials for those remote databases in configuration (just like you do for credentials to the main database), and control access to those connections through your application. Jan 13 '14 at 19:47
  • They do not. As I explained in the question, it is required that the users do not provide such credentials. They only supply LDAP credentials fro the PHP app. The PHP app will then access remote MySQL servers and perform some operations. Jan 13 '14 at 20:25
  • 3
    What is wrong with using MySQL+SSL, iptables and storing credentials in a config file for the web app? Jan 15 '14 at 17:53

You just need to store the configuration in a file that is only accessible to the user that PHP is running as. You can prevent a web user from accessing the file, but PHP has to be able to get to the credentials and no matter what you do, they will be effectively unprotected. Any secret you could give the application could be discovered, so there isn't any real advantage to trying to make some complex chain.

Beyond just the configuration file, you should also ensure that the SQL account that your webserver uses can only be used from the IP of the webserver and that it only has the rights needed for the webserver. If your webserver gets hacked, then they will get the webserver's access to the DB, but if your webserver is that hacked, they could also just replace scripts to make the webserver access it however they want anyway.

  • Thank you. Apologies, I can't vote up right now since I don't have enough reputation here. Jan 15 '14 at 19:50
  • This is the right approach. If you properly chmod the configuration file, keep it above the web root, and control privileged access to your system, the credentials are as safe as they can be.
    – Dan
    Jan 20 '14 at 21:56

I presume you are on a dedicated server? If you're on shared hosting it is almost impossible to secure PHP scripts.

A reasonable approach is to store the passwords in a dedicated configuration file and restrict the file permissions so this is only readable by the owner.

I expect people will cry "oh but they're not encrypted". The thing is, your application needs the plaintext passwords to connect to the database. So if you encrypt the passwords, you also need to have the key available, which defeats the point. I've seen all sorts of crazy proposals to improve on this, but all they do is add complexity without adding any meaningful security.

  • 1
    It is indeed a dedicated server. BTW, apologies, I can't vote up since I don't have enough reputation here. Jan 15 '14 at 19:49
  • I can imagine the type of complexity you're talking about. For example, encrypting the passwords in the database and using a plaintext cipher in the config file. While it is almost meaningless in terms of security, it does group the data correctly: suppose the remote instances hostname+port are stored in your local database; putting the encrypted passwords in same table makes sense and your database can also actually vouch for their existence (ie a NOT NULL column), whereas if you put them in a config file you cannot trivially enforce such constraint. Makes sense? Jan 16 '14 at 5:47

Another solution is to directly implement a ssh client within your application and depend on third party libraries such as JSch or extend either ssh/ssh-agent to directly receive and decrypt the key from your database.


Important thing is what you are trying to achieve by storing the key in the database encrypted.

An attacker that is able to access the temporary private key file will be able to read the ssh client process' memory as well (and hence get to the key data anyway), because both of these data must have basically the same access permissions - trying to hide the file doesn't seem to make it any more secure.

If you are using different users for db, webapp and ssh connection, by storing the key in the db, decrypting it in the webapp and feeding it to ssh, you are just opening potential attack vectors by spreading the key all over the process. If you are using just one user for all of these (db, app, ssh), you are gaining nothing except for code complexity.

The only advantage seems to be an easier transfer of the system to a different host and potential gain in case the db data gets stolen but the webapp (which AFAIU contains the decryption algorithm and password) not. But is that likely?

That said, if you want to protect the key, you can also use the ssh's internal encryption of the keys and load them into an ssh-agent when starting your service (remember to remove it when it stops!). But again remember that the ssh-agent keeps the keys in memory unencrypted, so it can potentially be read. Yet again: is this the problem you are trying to solve?

If you just need to protect communication between two machines, stunnel might be of better service than ssh.

  • 1
    This answer needs more upvotes - mysql afaik is unencrypted, so that password is going to be sent in the clear across the network/internet, and that other host should not be listening to the internet if it can avoid it.
    – pacifist
    Jan 20 '14 at 1:00
  • mysql supports working over SSL.
    – StasM
    Jan 20 '14 at 7:29
  • MySQL passwords are not being sent in plaintext even when not using SSL. Jan 20 '14 at 20:31
  • @Gexos, "directly receive and decrypt the key from your database" -- from which database? Do you mean the password should reside on the remote database itself? On the remote database host? Jan 20 '14 at 20:33
  • Where ever that is, i don't mean about where the password should reside. I edited a bit my answer cause i cant right more here.
    – user32084
    Jan 20 '14 at 20:48

Generic answer about Question title

There is two way of doing this.

1. Having password not stored in the server

This could be, but of course nothing could work without this essential key!

In this case, your application server have to ask for password on each boot.

This require an human administrator responsible of starting server every time any failure occure and/or maintenance implie server reboot.

2. Having password stored in the server.

Of course, the rights level used to serve webpages is not same than right level used to manage the server!

But this is the only really important thing.

You could do some hardening: hide password by using hiden files, picture stegano, or else, but this is a little useless:

The only important thing is to prevent privilege escalation:

Once bad guy reach high privilege in your server, following step-by-step the boot process for retrieving the way used by the server for reading his credential is as easy as eating a piece of cake.

Generic answer about builded app on GNU/Linux.

The simpliest way of ensuring correct storing of all credentials on complex structured systems is simply to install Debian GNU/Linux with only base system, than install only required servers following Debian documentation first.

Once all correctly installed, I take a lot of time for browsing all docs, before doing my own configuration.

There come a test step, making them running in my local domain.

Only when I think having sufficiently understood how this work, I could place this on plublic network.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.