Cloudify CLI stores user password in plaintext

[esmcelroy]

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.

[isaac-s]

@esmcelroy thank you. I have escalated internally.

[esmcelroy]

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:

• allow reading passwords from some environment variable
• allow user-input of passwords on execution

[esmcelroy]

This means, specifically, allowing profile creation without passwords, and implementing a read of an environment variable for user passwords (or user-inputted passwords)

[geokala]

@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]

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]

@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.