setting passwords via command line arguments is insecure

Bug #1031466 reported by Tim Spriggs on 2012-07-31
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
OpenStack Identity (keystone)
Undecided
Unassigned

Bug Description

% 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/

Thierry Carrez (ttx) on 2012-08-01
security vulnerability: yes → no
visibility: private → public
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers