Security issue: setpassword command exposes password on command line

[jtpereyda]

The anchore-cli account user setpassword appears to only allow the password to be specified in the command line arguments. Command line arguments can be exposed to other users on the OS, can end up in logs (such as bash history), etc. See https://cwe.mitre.org/data/definitions/214.html for more info on this type of vulnerability.

Password changes are a natural fit for an interactive UI, as they rarely need to be scripted. The getpass module makes getting the input easy.

> anchore-cli account user setpassword --help
Usage: anchore-cli account user setpassword [OPTIONS] USER_PASSWORD

Options:
  --username TEXT  Optional user name
  --account TEXT   Optional account name
  -h, --help       Show this message and exit.

Partial workaround: One can keep bash commands out of bash history by starting them with a space, assuming their system is configured properly. This trick is not universally known and not everybody will use it.

[zhill]

Thanks @jtpereyda, we'll take a look at the getpass module. Often we recommend folks using environment variables to pass the actual value in, but that too isn't an ideal solution since it has to get into the env somehow, such as sourcing a file or an export that can also end up in bash history or logs.

anchore-cli account user setpassword ${mynewpassword}

I agree the getpass looks preferable for normal behavior, and we can also look at click's password handler: https://click.palletsprojects.com/en/8.0.x/options/#password-prompts