Add support for getting token from password managers?

[NateEag]

Hey, I wanted to send some messages to Slack programmatically and this script seems to do the job nicely. Thanks!

I didn't see how to store the Slack API token securely, though, instead of just leaving it in plaintext on disk. I generally use pass to do this job.

So, in my dotfiles I added support for a SLACK_CLI_TOKEN_CMD environment variable. It just contains a command that will print the token to standard output.

Any interest in a PR to support password managers? If yes, does the above seem like a reasonable basis for one?

[shaleh]

Looks reasonable.

[rockymadden]

@NateEag Thanks for the idea! My hesitation thus far is thinking through attack vectors this might open that could be considered "unreasonable". Thoughts? Prior art?

[shaleh]

git's credential cache. https://git-scm.com/docs/git-credential-cache

[NateEag]

@rockymadden I'm not a security expert, and I don't have a good answer off the top of my head, but I'll type about this for a bit and see if anything useful comes out.

If you populate the env variable from a file that's world- or group-readable, a local user could use this to see what command you use to fetch your Slack CLI token.

However, the way Slack CLI works now, local users can see the Slack token directly, since the token is stored in plain text.

Chewing on it some, I guess the curl commands that specify the token directly might wind up in bash command history? That's one attack vector I've heard of that I hadn't thought about.

If that happens here, then the SLACK_CLI_TOKEN_CMD would be giving a false sense of security, which is one of the worst things it could do.

I might also be wrong about how safe it is to store secret values in bash variables. I believe if a variable isn't exported, all the OS protections that apply to process memory should apply to them, and so they should be reasonably safe, but like I said, I'm not a security expert.

[shaleh]

Reasonably correct.

Anyone with root privileges on a Linux machine can look in /proc and /mem and go digging. But you are supposed to trust them. Otherwise environment variables are reasonably secure. When they fail plenty of other things have failed too.

Bash command history is handled by the same file permissions that the .slack file has. If someone can look in your home directory and read file then they can read your history. But curl won't end up in that history because the history is only commands run from the prompt.

[rockymadden]

@NateEag and @shaleh If you both are good, I am as well.

[shaleh]

@rockymadden if you mimic git you should be solid. The git config lets you specify a program to run when credentials are needed. This program takes known parameters and returns a password on stdout (which git is reading from via pipes). This way there is no leaking.

[NateEag]

Given @shaleh 's comments I think we should be fine. What he described from git is what I've done.

I'm really busy right now (moving this weekend), so there won't be a PR from me right now.

If you're comfortable with the change as I made it in my dotfiles (linked above), feel free to go ahead and commit that patch yourself.