Re: Commands with passwords as options

["Benjamin R. Haskell" <zsh@benizi.com>]

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