Are 1password shell plugins promoting bad security behavior

[pulasthibandara]

op CLI version

all

Goal or desired behavior

For platforms that support short-lived access tokens through their own CLI tools (ex: gh/aws), the 1password plugin accepting potentially long-lived access token potentially degrades security posture of these tools. For a user unaware of the difference, this is a potential risk.

Examples:

• Aws: aws sso login --sso-session <account-name> creates short lived tokens
• Github: gh auth login craete a token for the shell and stores in system keychain

Current behavior

1password requests the user to create a token (potentially not-expiring due to the steps involved in the manual propcess).

Relevant log output

[scottisloud]

Hi @pulasthibandara

At the end of the day I think it comes down to being thoughtful about the specifics of your security posture, threat model, and risks. And I think it requires thought about what makes sense for a specific CLI tool. As you note, different CLI tools have different ways of authenticating, and different tools carry different risk.

But given the choice between a long-lived token in plaintext in ~/.config or persistent in an environment variable, or using a 1Password Shell Plugin, the shell plugin is a safer choice.

But where a CLI offers some more secure auth methods such as an SSO login with short-lived tokens, then shell plugins may not offer benefit or may be inferior to those other auth methods.

What it comes down to is: not every tool that exists in the world will excel in every situation every time. Shell plugins are no different. There are plenty of places where those more secure authentication options may not be available for a tool, or may be available but not accessible to a given user (e.g., if you don't have SSO, then SSO-based auth doesn't help you).

Security is a spectrum and it's highly contextual. We all have to be careful and thoughtful about which tools we use, when we use them, and how.

You have to decide whether a shell plugin is a security improvement over other auth methods for a given CLI tool or not, and that's a decision that we can't make for you. All we can do is provide options and tools for you to use at your discretion.

This is a really important point you are making, and I'm glad you shared it. We all need to think about this and make intentional security decisions for the tools we use and the context we use them in.

Thanks for sharing your thoughts!