Cloudify CLI stores user password in plaintext #910
Copy link
Copy link
Open
Description
When a user's profile is saved, it dumps the yaml profile settings into plaintext;
cloudify-cli/cloudify_cli/env.py
Lines 493 to 506 in 2fd55e0
| def save(self, destination=None): | |
| if not self.profile_name: | |
| raise CloudifyCliError('No profile name or Manager IP set') | |
| workdir = destination or self.workdir | |
| # Create a new file | |
| if not os.path.exists(workdir): | |
| os.makedirs(workdir) | |
| target_file_path = os.path.join( | |
| workdir, | |
| constants.CLOUDIFY_PROFILE_CONTEXT_FILE_NAME) | |
| with open(target_file_path, 'w') as f: | |
| f.write(yaml.dump(self)) |
This presents a security risk on shared systems, with multiple users.
Reactions are currently unavailable
Metadata
Metadata
Assignees
Labels
No labels
Activity
isaac-s commentedon Jan 26, 2019
@esmcelroy thank you. I have escalated internally.
esmcelroy commentedon Jan 28, 2019
As discussed with @isaac-s elsewhere, this isn't necessarily a bad behaviour, but it does not provide the flexibility to circumvent this on a shared system.
Potential workarounds would include:
esmcelroy commentedon Jan 28, 2019
This means, specifically, allowing profile creation without passwords, and implementing a read of an environment variable for user passwords (or user-inputted passwords)
geokala commentedon May 21, 2019
@esmcelroy Worth noting that the env var approach is not a good workaround if we're positing that the multiple users have the ability to read each others home directories, etc, as that implies they can probably also read /proc//environ. The prompting for a password could be good though.
esmcelroy commentedon Sep 27, 2019
Another potential implementation could see the user prompted for a password on first run - at which point, the CLI requests a token, which it can cache with a timeout timestamp, creating a session that will remain valid for the length of the token. On token expiry, it requests the user password again
geokala commentedon Sep 27, 2019
@esmcelroy Perhaps better for that approach would be something similar to the old gmail app-specific-passwords- probably in the form of tokens, but then that would allow issuing something that, e.g. a CLI on a shared machine could use which could later be revoked/disabled.
I'm not sure what the internal visibility on this issue is at the moment, but I'll pass it on for attention.