Password Protect OAuth Token Related Methods

[JosephAllen]

Can we get a password parameter added to all of the http related call that use OAuth related tokens?

The key.json and/or local keychain concept it too easy to exploit.

Adding a password parameter to the various CLI methods would allow for the use of local encryption without exposing an org to a hacked Admin/Dev machine.

Yes, it would be possible to grab the password via a key logger, but simple password protection would be a significant security improvement over the current CLI.

[github-actions[bot]]

Thank you for filing this feature request. We appreciate your feedback and will review the feature at our next grooming or sprint planning session. We prioritize feature requests with more upvotes and comments.

[uip-robot-zz]

This issue has been linked to a new work item: W-10023371

[mshanemc]

Where does the password come from? We don't put secrets in flags (they'll end up in shell history!), so there are commands that prompt a user to enter a credential. We typically store those, encrypted locally.

Without locally storing it, users would have to enter the password on every command that interacts with any org (which would block scripting use cases).

Do you have some examples of some commands that you'd want to have a password option, and drafts of their usage?

[JosephAllen]

@mshanemc, you are correct that each method would need the password parameter, but the parameter can be set via environment variable and/or passed from the parent Application, like VS Code.

From a shell

sfdx auth:list --json --password Mypassw1234

From a script:

## set the password parameter
$password = "Mypassw1234"

# retrieve the password for use
sfdx auth:list --json --password + &password 
sfdx force:apex:execute -u testusername@salesforce.org -f ~/test.apex --password + &password 

VS Code Extensions support using environment variables like this:

process.env.SFDX_PWD = "Mypassw1234";

# retrieve the password from the environment variable
sfdx auth:list --json --password + process.env.SFDX_PWD

[AllanOricil]

@mshanemc You could also use this idea to allow us to have access to the refresh token. If the developer pass the password parameter, or an ENV variable called SFDX_PWD is available, then print the refreshToken in the output of sfdx auth:list --json.

#956

[JosephAllen]

@AllanOricil

Bravo!

[AllanOricil]

I just thought about it again. It will never be secure. If a hacker access your computer he is able to retrieve any ENV variables you have there. He would still be able to get access to your orgs through sfdx. That was the reason I also closed that feature that request access to the refresh token.
But, it would be nice to have control over it, knowing the risks.

[JosephAllen]

@allan we need to figure out credentials management.

Sharing OAuth tokens is a fail for the IAM Designer exam. This vulnerability affects AWS and Azure CLI too.

The CLI is gonna get banned once CISO leadership realizes the vulnerabilities it introduces.

Some options are:

1. Password protect each command that requires a token to execute a web request
2. Create a shell (like sqlcmd or pwsh) that requires a password for connecting to local resources
3. Enable some feature like https://github.com/99designs/aws-vault
4. Move the key.json file and/or local alias json files to a user defined directory and have them write a custom bat file which will copy the files to ~/.sfdx and then delete after command execution
   • Copy file back to ~/.sfdx
   • Run commands
   • Delete ~/.sfdx files
5. Have users add another layer of encryption on top of the user_name.json files
   • Decrypt ~/.sfdx files using password
   • Run commands
   • Encrypt ~/.sfdx files using password

[AllanOricil]

related oclif/oclif#1157

[mshanemc]

there should not be secrets (ex: passwords) in flags. That's too easy to end up in shell history, and is inviting people to use them in scripts.

prompting the user for some sort of password interactively would be possible. It would make commands unscriptable.