setting passwords via command line arguments is insecure

[Tim Spriggs]

% keystone user-create --name "test" --tenant_id 0 --pass 'testing123' --email <email address hidden> --enabled true

CLI arguments are kept in shell history:

% history | grep pass | tail -1
  458 keystone user-create --name "tims" --tenant_id 0 --pass 'testing123' --email <email address hidden> --enabled true

Also, command line arguments show up in a ps listing:

% keystone user-create --name test --tenant_id 0 --pass 'testing123' --email <email address hidden> --enabled true
^Z
[1]+ Stopped keystone user-create --name test --tenant_id 0 --pass 'testing123' --email <email address hidden> --enabled true
% ps afx | grep keystone
 1465 ? S 0:00 /usr/bin/python /usr/bin/keystone-all
15262 pts/3 T 0:00 \_ /usr/bin/python /usr/bin/keystone user-create --name test --tenant_id 0 --pass testing123 --email <email address hidden> --enabled true

Finally, keeping tokens/credentials in the environment can lead to someone stealing the token. The environment is not always a safe place to hide things and many times setting something in the environment leaves behind a history as well.

Being able to specify new passwords via stdin or a secret file would be useful.

Also, it would be nice if there were a standard file (path? set of paths?) that keystone would look in if there are no tokens specified for client actions. Something along the lines of:

~/.keystone_auth
~/.keystone_token
... or even borrowing from the idea of an ssh-agent, some kind of socket in /var/tmp/