Zsh Mailing List Archive
Messages sorted by: Reverse Date, Date, Thread, Author

Re: Commands with passwords as options



On Tue, 1 Feb 2011, Julien Nicoulaud wrote:

OK, but at least it is hidden from the shell "UI". Take it as "man-looking-over-your shoulder" protection :-) For example you show something to someone, you do a backward history search and a command with a clear text password you forgot to exclude from history pops out...

In general, just avoid ever using such options. But, if you get lazy, two ways around it that I use:

# method 1, use a var:
$ read DBPASSWORD
*password*here*
$ <ctrl-l> to clear screen
$ mysql -u username -p$DBPASSWORD [...etc...]

# method 2, use a file:
$ cat > passfile
*password*here*
$ <ctrl-l> to clear screen (or just have the file from a past session)
$ mysql -u username -p$(<passfile) [...etc...]

Neither is "secure", in the way Mikael points out. (The command as it's being run has the password visible.) And the first is really for one-off,but-frequent situations. (i.e. when you're really just sick of typing the same password over and over.) The second method I use quite a bit, for not-actually-secure passwords.

Generally (but not always) things that allow you to specify the password on the command line also let you specify a password file on the command line, which is at least one step better.

e.g. mysql has ~/.my.cnf
rsync has --password-file=
ldapsearch has -y
smbclient has -A

For SSH/GPG passwords, there are ssh-agent and gpg-agent. Other programs have similar things. That lets you avoid typing the password over-and-over at the risk of requiring the password only once during a given time period or login session.

For anything for which you want *real* security, the answer is to, of course, type it every time you need it. (For my money, ssh-agent makes the best security vs. convenience tradeoff.)

--
Best,
Ben



Messages sorted by: Reverse Date, Date, Thread, Author