The irony of a security improvement which is equally insecure

jscarle
jscarle
Community Member
in CLI

I have an issue with the improvement detailed in the 1.12.2 CLI update: https://1password.community/discussion/123986/command-line-tool-v1-12-2-op-create-item-template-file-json

Micheal mentions that the op encode command is now officially deprecated and will be removed in future versions of the CLI. The reasoning is that "Passing your about-to-be-created vault item details to op as a command-line argument is insecure". Now I agree that is the case, because of the further mentioned "other users or processes to see the arguments that are passed to any program, which means that they would be able to see your vault item details for the window that op create item is running".

That's all well and good, however there's an irony in remplacing this insecure method with another insecure method. One could argue that between the two, a file import is less insecure that command line parameters which could be logged, however it is incorrect to think that a file import is "secure".

Unencrypted files are inherently insecure. Even temporary files remain inherently insecure as any deleted files can be easily recovered.

Please consider adding stdin as an input method to op create item in the same way that stdin can be used with op create document. Something as simple as a single dash such as op create item Login - could work as a syntax just as it does with op create document. This would give an alternative that doesn't require the creation of insecure plain text files while also eliminating logging of the command line arguments.

1Password Version: Not Provided
Extension Version: Not Provided
OS Version: Not Provided

Comments

  • Michael_1P
    Michael_1P
    edited November 2021

    Hey @jscarle,

    Thanks for writing in with your concern. We always appreciate feedback. I'm happy to add stdin as an input method to op create item to our roadmap. ref: dev/b5/op#1754 As you mention, there are definitely use cases where that is the best, most secure option. It's certainly the best option for, say, a .NET wrapper around our command-line tool 😉

    One of the considerations that we make throughout all of our products is to aim for a secure default. We clearly missed the mark when asking users to pass vault item details as a command-line argument. As part of adding support for stdin, we'll want to make it clear to users how to securely use that as well.

    I'd like to push back on the idea that storing the template JSON is equally insecure. When we asked users to pass their details as command-line arguments, there was little that a user could do to protect themselves. When writing to and editing a file, on *nix-like systems, we can ask users to set umask 077. On Windows systems, working in your own $HOME directory is the safest option (to our knowledge, at least!). And we can instruct users to take these precautions. You're correct in that deleted files can be recovered, but we still feel that this is a _safer_ option than what we had before.

    And, to your point, I think that having an option where we read from STDIN would also be acceptable from a security perspective.

    I hope that this helps. Let me know if you have any additional questions or feedback.

    Michael

  • jscarle
    jscarle
    Community Member
    edited November 2021

    That's some great news as it will allow the use of non-file based inputs, whichever the source. Thank you very much!

    As for the $HOME directory, that's a Linux variable. The mistake is equally present on the documentation page. The Windows equivalent to cd $HOME would in fact be cd %USERPROFILE%.

    In order to improve security by preventing command-line logging, there would also need to be an improvement made to op edit item (https://support.1password.com/command-line-reference/#edit-item) as there is currently no other way to edit an existing item other then to hand over a list of assignments.

    Personally, I would love to see the addition of --filename <path> with the option to specify stdin in the same way as edit document does (--filename -). This would allow sending the full json of an existing item (either through a permission secured local file or through stdin) without logging any of the changes on the command-line.

This discussion has been closed.