What are secure approaches to handling a script that requires a database (MySQL) password?

Question

Obviously, we don't want to hardcode the plaintext password in each script. This would make cycling the password difficult since a ton of scripts would need to be changed in addition to the password being in plaintext in the first place.

If the scripts takes the password as a parameter, then we need to worry about modifying the 'ps' output to not show the password argument's value. We would also have to worry about the command being recorded in shell history. This can be potentially handled via HISTIGNORE/HISTCONTROL on bash, but there are other shells in use with differing and less flexible history control (e.g.: zsh). We could also use a commandline-specific environment variable (FOO=bar ./script), and while the 'FOO=bar' won't show up in 'ps', it's still, by default, recorded to the shell history. Besides, some systems expose other user's process environments (via 'ps') anyway.

A password (configuration) file could be used that simply stores the plaintext password. This file could be owned/permissioned such to tighten up its access. But, at the end of the day, you still have a password in plaintext.

Prompting is also an option, but this tends to be less convienient (still possible via expect, for example, though) and complicates non-interactivity if the script requires such.

Encryption of some flavor could be used but then we still have a similar issue to deal with with the decryption key.

Should I just go with one of the above anyway? Are the other options that might be superior? How do people handle this situation is a secure manner?

The general goal here is that an attacker should not be able to comprise the database server if the attacker somehow gets onto a system that makes use of the database server. For example, an attack shouldn't be able to just find the password lying around somewhere, shouldn't be able to observe the system ('ps') to discover it, and shouldn't be able to "look back in time" (shell history) to find it.

I'm perfecting aware that there are a millions of scenarios (kmem, swapped pages, etc.. etc..) and that most bets are off if the attacker gets root or physical access and that nothing is going to be 100% secure. I'm just really looking for the best approach within reason. :-)

Answer 1

You can put a .my.cnf file in the home dir(s) of users that can access the script, with their info and mysql can read it from there instead of the command line. You'll also have to set an environment variable to point at ~/.my.cnf, but... I'm not sure if it's MYSQL_HOME or SYSCONFDIR or something else*. It'd still be a plain text file, but if you restrict that file to owner-only, it should be fine? It'll at least keep passwords out of ps.

MySQL: Option Files and MySQL: Password Security doc pages both hint at this a little.

(*disclaimer: I'm no admin by any definition, just enough to get in trouble)