存储数据库密码的最佳实践

Question

I am developing a custom server application that will access a database. I need to decide where I will store the credentials (and to address) to that server.

A common solution is to put the credential in a config file. However, I do not want a compromised server to mean that the hacker has access to the DB (which is hosted on a separate server).

I could store the credentials in the environment, but that is just security through obscurity. Mr. Evil can just look in the environment to find it.

Someone suggested encryption. However, if I store the key in the executable, a quick de-compile (we are using Java) and I am still doomed.

I also want to avoid having to enter a paraphrase every time I start the server.

Any suggestions? I feel like I'm missing something simple.

Thanks

Answer 1

I don't think you're missing something simple. Either the server in question can connect to the database without your help, in which case it has to have the credentials; or it cannot connect without your supplying them. You can take various steps like the ones you've listed to make it harder for a compromised server to reveal the credentials to the database, but at the end of the day, if it has to have those credentials and supply them to the DB server to connect, they'll have to be stored on it somewhere — or at least, it will have to have some means of getting them, and so will be hackable in that sense.

Your best bet is to focus on finding out about intrusions (compromised servers) as quickly as possible, keeping good off-site, off-line backups for the worst case, putting up lots of barriers to intrusion in the first place, etc.

Answer 2

I am sharing, the way I had solved this.

• Build API, to query the authentication details from a foreign domain.
• Use public key, and private key to read through the details.

But, honestly the only thing this did was over complicate simple things. After that, I created several users to the database, with different privileges.

Like

• guest can only to SELECT
• mod can only CREATE , INSERT , UPDATE , DELETE

etc and switched the user, whenever authenticated users appeared.

With the combination of users and session, I have been able to escape the threats so far. But ofcourse the code vulnerability have to be tested thoroughly.

Answer 3

Lock it down. Prevent Mr. Evil from gaining root. I know, easy right?

Write a secure application and keep your application server locked down. Follow best practices there, and that's most of the work.

When I've setup databases in a secure environment, the only server that was on the same physical network with the database server was the application server. There were two ways to access the database server:

1. Application server
2. Console

Therefore, in order to compromise the database server, they'd have to compromise the application server.

So, lock down the application server. Of course the only thing worse than being compromised is being compromised and not knowing about it. If you do discover a compromise, you need to fix the vulnerability if there was one. Forensics are important here (enable logs and monitor them). You also need a recovery plan in place.

Prevention, detection, correction, and recovery are paramount.