Best practice for storing database password
Question by beshiros
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 by T.J. Crowder
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 by Starx
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
guestcan only toSELECTmodcan onlyCREATE,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.
