Commands with passwords as options

Commands with passwords as options

[Julien Nicoulaud]

[-- Attachment #1: Type: text/plain, Size: 600 bytes --]

Some commands take passwords as option values, which is not very secure... I
was wondering if there is some way to handle that, for example through a
custom completer. Ideally, I here is how it should behave:
 - When reaching an option which expected value is a password, prompt for it
and read it from stdin
 - Do not display it in the buffer (just replace it with "XXXX" for example)
 - When accepting the buffer, replace the displayed buffer with the real one
 - Save the displayed buffer in the history rather than the real one

Does anyone have an idea on how to achieve this ?

Regards,
Julien

Re: Commands with passwords as options

[Mikael Magnusson]

On 1 February 2011 22:15, Julien Nicoulaud <julien.nicoulaud@gmail.com> wrote:
> Some commands take passwords as option values, which is not very secure... I
> was wondering if there is some way to handle that, for example through a
> custom completer. Ideally, I here is how it should behave:
>  - When reaching an option which expected value is a password, prompt for it
> and read it from stdin
>  - Do not display it in the buffer (just replace it with "XXXX" for example)
>  - When accepting the buffer, replace the displayed buffer with the real one
>  - Save the displayed buffer in the history rather than the real one
>
> Does anyone have an idea on how to achieve this ?

That doesn't actually achieve anything, the password is still visible
in /proc/<pid>/cmdline.

-- 
Mikael Magnusson

Re: Commands with passwords as options

[Julien Nicoulaud]

[-- Attachment #1: Type: text/plain, Size: 1164 bytes --]

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...

2011/2/1 Mikael Magnusson <mikachu@gmail.com>

> On 1 February 2011 22:15, Julien Nicoulaud <julien.nicoulaud@gmail.com>
> wrote:
> > Some commands take passwords as option values, which is not very
> secure... I
> > was wondering if there is some way to handle that, for example through a
> > custom completer. Ideally, I here is how it should behave:
> >  - When reaching an option which expected value is a password, prompt for
> it
> > and read it from stdin
> >  - Do not display it in the buffer (just replace it with "XXXX" for
> example)
> >  - When accepting the buffer, replace the displayed buffer with the real
> one
> >  - Save the displayed buffer in the history rather than the real one
> >
> > Does anyone have an idea on how to achieve this ?
>
> That doesn't actually achieve anything, the password is still visible
> in /proc/<pid>/cmdline.
>
> --
> Mikael Magnusson
>

Re: Commands with passwords as options

[Benjamin R. Haskell]

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

Re: Commands with passwords as options

[Mikael Magnusson]

On 1 February 2011 23:40, Benjamin R. Haskell <zsh@benizi.com> wrote:
> 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

You can use read -s here and the password will not be echoed to the
screen as you type it. For cat you can use "STTY=-echo cat"

-- 
Mikael Magnusson

Re: Commands with passwords as options

[Bart Schaefer]

On Feb 1, 10:15pm, Julien Nicoulaud wrote:
}
} Some commands take passwords as option values, which is not very
} secure... I was wondering if there is some way to handle that, for
} example through a custom completer.

I don't know about a custom completer -- it's pretty difficult to
have the completion system go off and do something interactive in
the middle, at least not without the display ending up hopelessly
muddled afterward -- but it should be possible to implement it as
a widget.

send-invisible() {
  emulate -L zsh
  # Shamelessly cribbed from read-from-minibuffer.

  # send-invisible reads a line from the terminal, displaying an
  # asterisk for each character typed.  It stores the line in the
  # global variable INVISIBLE, and when finished reading, inserts
  # the string ${INVISIBLE} into the original command buffer.

  # If one argument is given, it is the prompt.  The default is
  # "Non-echoed text: "

  # If two or three arguments are given, they form the prefix and
  # suffix of the inserted INVISIBLE.  Defaults are '${' and '}'
  # but these can be replaced, for example with '"${' and '}"' to
  # enclose the whole word in double quotes, or '${(z)' and '}' to
  # split the value of $INVISIBLE like the shell parser.

  # Hide the value of INVISIBLE in any output of set and typeset
  typeset -g -H INVISIBLE=

  local pretext="$PREDISPLAY$LBUFFER$RBUFFER$POSTDISPLAY"$'\n'

  # Can't directly make these locals because send-invisible is
  # called as a widget, so these special variables are already
  # local at the current level and wouldn't get restored
  local save_lbuffer=$LBUFFER
  local save_rbuffer=$RBUFFER
  local save_predisplay=$PREDISPLAY
  local save_postdisplay=$POSTDISPLAY
  local -a save_region_highlight
  save_region_highlight=("${region_highlight[@]}")

  {
    local lb rb opn=${2:-'${'} cls=${3:-'}'}
    LBUFFER=
    RBUFFER=
    PREDISPLAY="$pretext${1:-Non-echoed text: }"
    POSTDISPLAY=
    region_highlight=("P${(m)#pretext} ${(m)#PREDISPLAY} bold")

    while zle -R && zle .read-command
    do
      # There are probably more commands that should go into
      # the first clause here to harmlessly beep, because ...
      case $REPLY in
      (send-invisible|run-help|undefined-key|where-is|which-command)
        zle .beep;;
      (push-*|send-break) INVISIBLE=;&
      (accept-*) break;;
      (*)
        LBUFFER=$lb
        RBUFFER=$rb
        zle $REPLY	# ... this could expose something
        lb=$LBUFFER
        rb=$RBUFFER
        INVISIBLE=$BUFFER
	LBUFFER=${(l:$#LBUFFER::*:):-}
	RBUFFER=${(l:$#RBUFFER::*:):-}
        ;;
      esac
    done
  } always {
    LBUFFER=$save_lbuffer
    RBUFFER=$save_rbuffer
    PREDISPLAY=$save_predisplay
    POSTDISPLAY=$save_postdisplay
    region_highlight=("${save_region_highlight[@]}")
    zle -R

    # Now that the highlight has been restored with all the old
    # text and cursor positioning, insert the new text.
    LBUFFER+=${INVISIBLE:+${opn}INVISIBLE${cls}}
  }
}
zle -N send-invisible

} Ideally, I here is how it should behave:
}  - When reaching an option which expected value is a password, prompt for it
} and read it from stdin

If you can figure out how to auto-invoke the above in these circumstances,
go for it.  Possibly something in zle-line-init that examines the word
at the end of $LBUFFER.

}  - Do not display it in the buffer (just replace it with "XXXX" for example)
}  - When accepting the buffer, replace the displayed buffer with the real one
}  - Save the displayed buffer in the history rather than the real one

I think the above covers all of this.

Re: Commands with passwords as options

[Julien Nicoulaud]

[-- Attachment #1: Type: text/plain, Size: 4033 bytes --]

2011/2/2 Bart Schaefer <schaefer@brasslantern.com>

> On Feb 1, 10:15pm, Julien Nicoulaud wrote:
> }
> } Some commands take passwords as option values, which is not very
> } secure... I was wondering if there is some way to handle that, for
> } example through a custom completer.
>
> I don't know about a custom completer -- it's pretty difficult to
> have the completion system go off and do something interactive in
> the middle, at least not without the display ending up hopelessly
> muddled afterward -- but it should be possible to implement it as
> a widget.
>
> send-invisible() {
>  emulate -L zsh
>  # Shamelessly cribbed from read-from-minibuffer.
>
>  # send-invisible reads a line from the terminal, displaying an
>  # asterisk for each character typed.  It stores the line in the
>  # global variable INVISIBLE, and when finished reading, inserts
>  # the string ${INVISIBLE} into the original command buffer.
>
>  # If one argument is given, it is the prompt.  The default is
>  # "Non-echoed text: "
>
>  # If two or three arguments are given, they form the prefix and
>  # suffix of the inserted INVISIBLE.  Defaults are '${' and '}'
>  # but these can be replaced, for example with '"${' and '}"' to
>  # enclose the whole word in double quotes, or '${(z)' and '}' to
>  # split the value of $INVISIBLE like the shell parser.
>
>  # Hide the value of INVISIBLE in any output of set and typeset
>  typeset -g -H INVISIBLE=
>
>  local pretext="$PREDISPLAY$LBUFFER$RBUFFER$POSTDISPLAY"$'\n'
>
>  # Can't directly make these locals because send-invisible is
>  # called as a widget, so these special variables are already
>  # local at the current level and wouldn't get restored
>  local save_lbuffer=$LBUFFER
>  local save_rbuffer=$RBUFFER
>  local save_predisplay=$PREDISPLAY
>  local save_postdisplay=$POSTDISPLAY
>  local -a save_region_highlight
>  save_region_highlight=("${region_highlight[@]}")
>
>  {
>    local lb rb opn=${2:-'${'} cls=${3:-'}'}
>    LBUFFER=
>    RBUFFER=
>    PREDISPLAY="$pretext${1:-Non-echoed text: }"
>    POSTDISPLAY=
>    region_highlight=("P${(m)#pretext} ${(m)#PREDISPLAY} bold")
>
>    while zle -R && zle .read-command
>    do
>      # There are probably more commands that should go into
>      # the first clause here to harmlessly beep, because ...
>      case $REPLY in
>      (send-invisible|run-help|undefined-key|where-is|which-command)
>        zle .beep;;
>      (push-*|send-break) INVISIBLE=;&
>      (accept-*) break;;
>      (*)
>        LBUFFER=$lb
>        RBUFFER=$rb
>        zle $REPLY      # ... this could expose something
>        lb=$LBUFFER
>        rb=$RBUFFER
>        INVISIBLE=$BUFFER
>        LBUFFER=${(l:$#LBUFFER::*:):-}
>        RBUFFER=${(l:$#RBUFFER::*:):-}
>        ;;
>      esac
>    done
>  } always {
>    LBUFFER=$save_lbuffer
>    RBUFFER=$save_rbuffer
>    PREDISPLAY=$save_predisplay
>    POSTDISPLAY=$save_postdisplay
>    region_highlight=("${save_region_highlight[@]}")
>    zle -R
>
>    # Now that the highlight has been restored with all the old
>    # text and cursor positioning, insert the new text.
>    LBUFFER+=${INVISIBLE:+${opn}INVISIBLE${cls}}
>  }
> }
> zle -N send-invisible
>
> Perfect, thank you !

You can unset INVISIBLE in precmd too:
  unset_invisible () {unset INVISIBLE}
  add-zsh-hook precmd unset_invisible


> } Ideally, I here is how it should behave:
> }  - When reaching an option which expected value is a password, prompt for
> it
> } and read it from stdin
>
> If you can figure out how to auto-invoke the above in these circumstances,
> go for it.  Possibly something in zle-line-init that examines the word
> at the end of $LBUFFER.
>
> I think the widget approach is the only one that will work in every case...


>  }  - Do not display it in the buffer (just replace it with "XXXX" for
> example)
> }  - When accepting the buffer, replace the displayed buffer with the real
> one
> }  - Save the displayed buffer in the history rather than the real one
>
> I think the above covers all of this.
>

Re: Commands with passwords as options

[Bart Schaefer]

On Feb 2, 10:27pm, Julien Nicoulaud wrote:
}
} Perfect, thank you !

You're welcome.  As soon as sourceforge gets our repository back on
line, I'll add it to Functions/Zle/.

} You can unset INVISIBLE in precmd too:
}   unset_invisible () {unset INVISIBLE}
}   add-zsh-hook precmd unset_invisible

Yes, but that doesn't really gain anything as the memory isn't really
erased; if someone can scan your process address space they're going
to find the password whether you've unset the variable or not.

I suppose it protects you from someone grabbing your keyboard and
typing "echo $INVISIBLE".

Hmm, that reminds me that you have to be careful with running a word-
expanding widget after $INVISIBLE is on the command line.  I'm not
sure how best to deal with that one ...

Re: Commands with passwords as options

[PJ Weisberg]

On 2/1/11, Julien Nicoulaud <julien.nicoulaud@gmail.com> wrote:
> Some commands take passwords as option values, which is not very secure... I
> was wondering if there is some way to handle that, for example through a
> custom completer. Ideally, I here is how it should behave:
>  - When reaching an option which expected value is a password, prompt for it
> and read it from stdin
>  - Do not display it in the buffer (just replace it with "XXXX" for example)
>  - When accepting the buffer, replace the displayed buffer with the real one
>  - Save the displayed buffer in the history rather than the real one
>
> Does anyone have an idea on how to achieve this ?
>
> Regards,
> Julien
>

This strikes me as something that's so insecure that it should LOOK
insecure.  Hiding it in the history file is ok, but if the password is
hidden on the command line the user will assume it's being hidden in
other ways, when that's not actually possible.
-- 

-PJ