hiding username/password in database scripts

Cody Pendant has asked for the wisdom of the Perl Monks concerning the following question:

Is there a generally acknowledged Best Practice way of hiding the username and password in a script which needs to access a database? Or, indeed, any other resource?

I was just noticing how the Movable Type people do it (see point 8, "Set your SQL database password").

Most of their information goes in a ".cfg" config file. But the username and password go in a separate file, which has the CGI extension, only without a shebang line. So even though everyone knows where it is, you can't execute it or view it, so you can steal the details.

Is this normal? What are they protecting against by going to all that trouble as opposed to just putting it in the script? Or in the config file? After all, as long as the config doesn't have a "Content-type: whatever\n\n" somewhere, I can't see that either.

Nobody says perl looks like line-noise any more
kids today don't know what line-noise IS ...

Comment on hiding username/password in database scripts

Replies are listed 'Best First'.
Re: hiding username/password in database scripts by kyle (Abbot) on Jan 13, 2008 at 03:26 UTC
This was discussed recently (a month ago): hiding database passwords	[reply]
Re: hiding username/password in database scripts by graff (Chancellor) on Jan 13, 2008 at 07:41 UTC
I don't know if your interests are at all similar to the scenario that started this old thread: Security: balancing two conflicting password policies -- but that was a very interesting thread, and you might find some useful stuff there.	[reply]
Re: hiding username/password in database scripts by gam3 (Curate) on Jan 13, 2008 at 15:10 UTC
I looked through the threads that were listed here and did not see any discussion of storing keys in memory. In this system you start a daemon that requires a password. That daemon can then be used to retrieve the password for the database. There are 2 commonly used examples of this approach, ssh-agent and gpg-agent and it is possible that you could use gpg-agent. Certainly this is not totally safe, but much safer than having the password on the harddisk. The password itself is only in memory for a short time and the key is sitting at some (hopefully) unknown place in memory. The down side is -- Just like if a password protected ssl key with apache -- you have to type in a password each time the daemon is started. -- gam3 A picture is worth a thousand words, but takes 200K.	[reply]
Re: hiding username/password in database scripts by hpavc (Acolyte) on Jan 13, 2008 at 16:55 UTC
This method or similar works "DBI:mysql:test;mysql_read_default_file=$ENV{HOME}/.my.cnf";	[reply]
Re: hiding username/password in database scripts by Cody Pendant (Prior) on Jan 13, 2008 at 22:31 UTC
Thanks for all the help. Sorry I didn't do much searching beforehand. My main focus, I should have said, is the less clueful user. I'm trying to create a script which anyone can drop in quickly and use with minimal setup. And this is presumably the reason why MT did it that way? What happens if you use the DBD approach mentioned above, but you can't trust your users to know how to set permissions correctly? Is their approach a bit kludgey, but justifiable in the context of security for people who don't understand security? I'm still not sure how the bad guys could get my username and password if I have it in a regular CGI script and don't use CGI::Carp or anything which would give out error specifics to a browser. Nobody says perl looks like line-noise any more kids today don't know what line-noise IS ...	[reply]
Re^2: hiding username/password in database scripts by WoodyWeaver (Monk) on Jan 14, 2008 at 00:03 UTC
I'm trying to create a script which anyone can drop in quickly and use with minimal setup... What are they protecting against by going to all that trouble as opposed to just putting it in the script? Because you want to maximize convenience and aren't greatly concerned about security, you should ensure your system is robust first. Then it is pretty easy to apply enough security to keep honest people honest -- by splitting the secret into two parts kept in separate locations. Movable Type's is the most honest, where the two parts are in easily read files. "hiding database passwords" had some similar sentiments (I actually like the very last idea, about storing it on a removable token that is used for boot.) The "Balancing two conflicting passwords" approach was to have the separation virtual, where the password is encrypted against a token associated with the script. None of these will protect against malice without additional controls, but that isn't the point here if the extracts are correct. If malice or non-repudiation is an issue, there are other things. Physical token plus operational controls can work, and there are technical controls with password servers and the like, but they are overkill for the kind of problem you describe, impo. (I play an IT Security Architect on TV.) --woody	[reply]