setting passwords via command line arguments is insecure
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
OpenStack Identity (keystone) |
New
|
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/
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/
security vulnerability: | yes → no |
visibility: | private → public |