CLI client exposes secret key passphrase length

[zmwangx]

Here's what I got on the command line just now:

> keybase push --update
info: Updating both remote keys with local version

----------------------------------------------------------------------
                     Enabling zmwangx@keybase.io
----------------------------------------------------------------------

All keybase users get a free @keybase.io address, which
forwards incoming mail and acts, for privacy, as the return
address on outgoing mail generated via `keybase email`.

This feature works **much** better with existing GPG clients
if you add zmwangx@keybase.io to your public key.

You have 3 options:

  (1) Exit now; I can add zmwangx@keybase.io with GPG or my own software
  (2) Allow keybase to add it for me
  (3) Skip this step and do it later (not recommended)

Your choice (2): 2

----------------------------------------------------------------------

OK. Keybase will now modify your public key by merging
zmwangx@keybase.io into its approved list of emails.  This
operation requires temporary local access to your secret
key and then throws it away. The client will not write
your decrypted secret key to disk or to the server.

Passphrase for key 'Zhiming Wang (github.com/zmwangx) <zmwangx@gmail.com>': *************************************************************
info: Updated file: /Users/zmwang/.cache/keybase/session.json
info: success!

As you can see, the passphrase is printed as a row of asterisks, whose number matches the passphrase length (I changed the actual number). Not cool. The client should behave like any other good Unix citizen: passphrase characters should never be echoed back to the terminal, not in any form. Imagine someone's passphrase has only five characters, and someone looked over his shoulder/exfiltrated his terminal logs and saw the five asterisks — now he's ready to brute force.

[ghost]

I agree and created a PR to fix this behaviour

[zmwangx]

Cool, thanks.