Reasonable way to store encrypted passwords in a webapp's database, Linux

Question

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?

Answer 1

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.

Answer 2

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.

Answer 3

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.

*EDIT*

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.

Answer 4

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.