[discussion] Secure Item in clipboard manager - non disclosure of password value
Hi, Recently, I forked xfce4 clipman (clipboard manager) to start a PoC of Secure Item + a cli to drive clipman via DBus call, that I also added to the forked code. This email is mostly a post is about security or non-disclosure of password. The Secure Item concept I introduced in clipman, try to hide the password all the time, until it is ultimately stored as clear text in the clipboard, and then delete after a short period ~30s. Example and code can be found and explained here: https://gitlab.xfce.org/Sylvain/xfce4-clipman-plugin/-/blob/secure_item_dbus/README.md <https://gitlab.xfce.org/Sylvain/xfce4-clipman-plugin/-/blob/secure_item_dbus/README.md> I also added a small obfuscation to avoid to reveal password in log, or DBus may be, or debug log, etc. As the PoC is only to test the idea it's sufficient but it could be crypted. I also hide the password that way during testing and developing the software, as I may still need to copy some password while using the clipboard manager in debug mode. How do you secure password fields (non-disclosure) in pass? I mean, what special effort did you add to ensure that clear password are avoided outside where it's expected. I also saw that the pass code hold some dbus call for org.kde.klipper. I will look how they handle that too in klipper code. Actually I'm testing the PoC and exploring how I could use it. I wrote a small shell wrapper for testing it: https://gitlab.xfce.org/Sylvain/xfce4-clipman-plugin/-/blob/secure_item_dbus/pass_clip.sh <https://gitlab.xfce.org/Sylvain/xfce4-clipman-plugin/-/blob/secure_item_dbus/pass_clip.sh> I suppose I should write a pass-extension plugin in order to use clipman-cli. I will think about it. could be: pass clipman add PASS_ENTRY pass clipman delete ID pass clipman clear_secure etc. Actually clipman_cli wrapper supports: # Usage: ./clipman_cli.sh add [-s] TEXT_ITEM_VALUE # ./clipman_cli.sh list # ./clipman_cli.sh del ITEM_ID # ./clipman_cli.sh get ITEM_ID # ./clipman_cli.sh get_secure ITEM_ID # ./clipman_cli.sh clear # ./clipman_cli.sh clear_secure # ./clipman_cli.sh set_secure ITEM_ID # ./clipman_cli.sh set_clear_text ITEM_ID # ./clipman_cli.sh collect_secure [NUM_COLLECTED_ITEM_TO_SECURE] # # Arguments: # TEXT_ITEM_VALUE string to add to history. # ITEM_ID uint16 a clipman history ID (use list or add # to retreive it). # NUM_COLLECTED_ITEM_TO_SECURE uint16 the next collected item from clipboard # will be set secured by clipman automatically. # Useful for keyboard shortcut before copying # [default: 1] My plan is to create a Merge Request in the main clipman code in order to publish something useful. Thanks for your attention, Remarks are welcome, Regards, Sylvain. -- Sylvain Viart - GNU/Linux Sysadmin/Developer/DevOps - France
Re: [pass] [PATCH] Allow custom subcommands - web of trust
Le 07/10/2016 à 09:41, Brian Candler a écrit : > > I can't see any way in which adding plugin signatures to pass itself > is helpful. How are you going to choose which signatures to trust? > Either pass is hard-coded with a list of trusted plugin authors, or > you have to add the author keys too. In which case this is no better > than either of the previous options. My message was to introduce signing for trust. It happens effectively somewhat in .deb packages (it could be other examples of course). Web of trust, is a way to delegate trust to other people in whom you trust, as far as I know. It was introduced long time ago in GPG, for example. You need to meet the person physically to fully trust his/her key. So by following the links of trusted signatures you may, or may not, arrive to trust a plugin using your own keyring. I don't know if it is needed here for pass, but the subject has been mentioned earlier in the link I posted. May be not on that form, but as more and more really good plugin arrive it could be interesting to think about that. The custom subcommands is really pleasing concept, and I was thinking loud how, and if, it needs to be achieved by signing custom scripts. I'm also interested of how a "community trust" of signed keys could behave, as it's also developed in free money software <https://en.duniter.org/>. Regards, Sylvain. -- Sylvain Viart - DevOps système linux - freelance developer signature.asc Description: OpenPGP digital signature ___ Password-Store mailing list Password-Store@lists.zx2c4.com http://lists.zx2c4.com/mailman/listinfo/password-store
Re: [pass] [PATCH] Allow custom subcommands
Hi, Le 04/10/2016 à 07:40, Brian Candler a écrit : > On 04/10/2016 05:45, Sylvain Viart wrote: >> Pass itself could be signed. By the user at init. > But why? Do you have a version of Linux which only executes signed > scripts/binaries? No, just an idea to share about. It could be a bad idea, of course… And also because web of trust is interesting me. :-) Not only signed scripts. > As for the admin being tricked into installing a malicious plugin - > what's the difference between that and installing a malicious version > of 'pass' itself? > > The only protection for 'pass' is installing it from a trusted > location, and/or verifying the code by eye. Surely the same applies to > plugins? You're right of course. But what about non-programmer user? I can't tell them to do that, right. Some time, (often) I don't have time to review the code myself, I need to trust the system, and free my mind about this issue. For example running a GNU/Linux distrib + passwordstore, lets say I'm trusting that, so I can go. That was more my point. .deb packages are signed and reviewed by some volunteer, I don't know if the system is perfect or not, but I'm trusting it. ;-) Sylvain. -- Sylvain Viart - DevOps système linux - freelance developer signature.asc Description: OpenPGP digital signature ___ Password-Store mailing list Password-Store@lists.zx2c4.com http://lists.zx2c4.com/mailman/listinfo/password-store
Re: [pass] [PATCH] Allow custom subcommands
Hi Thorsten, Le 03/10/2016 à 19:30, Thorsten Wißmann a écrit : >> > Does GPG web of trust sure enough, to allow co-signing script to enable >> > such signed plugins? > I don't understand your question. But are you asking how my patch could > be extended to call only 'signed' extensions? It was, yes. I also mention the "web of trust" behavior of GPG, which nice but complicated, just to see if some reader are involved in such reflexion… ;-) > If some bad guy has write access to some directory in $PATH and wants to > take over your password store, then the bad guy can simply add a > malicious `pass` executable and the user would not notice. Pass itself could be signed. By the user at init. I was more thinking, about installing malicious plugin, not having malicious inside your computer. I don't think than a password manager can be used on a share system, with shared memory or process… It is only designed to work on a personal computer. (I never though about that before but…) > I.e. I don't think `pass` should do something like signing of program > code. It's some separate problem to check if the programs in your $PATH > are trustworthy or not. I see your point, you may be right. I just emailed the reference about signing plugins to let you know. Not tested your plugin yet… I like the logic like git or rvm. Regards, Sylvain. -- Sylvain Viart - DevOps système linux - freelance developer ___ Password-Store mailing list Password-Store@lists.zx2c4.com http://lists.zx2c4.com/mailman/listinfo/password-store
Re: [pass] [PATCH] Allow custom subcommands
Hi Thorsten, Le 30/09/2016 à 11:33, Thorsten Wißmann a écrit : > if there is an executable pass-clipwiz in the PATH. This does not only > fit the usual pass workflow (first show a file, then paste it using > clipwiz), but one also gets the tab-completion for custom pass scripts > for free. Sounds cool! See also: [pass] Extending pass with user-defined hooks / add ons https://lists.zx2c4.com/pipermail/password-store/2015-August/001659.html Does GPG web of trust sure enough, to allow co-signing script to enable such signed plugins? Sylvain. -- Sylvain Viart - DevOps système linux - freelance developer signature.asc Description: OpenPGP digital signature ___ Password-Store mailing list Password-Store@lists.zx2c4.com http://lists.zx2c4.com/mailman/listinfo/password-store
Re: [pass] Proposal: fuzzy search
Hi, Le 15/08/2016 à 18:22, Kun Zhang a écrit : > Happy to see other people thinking the same thing :) I also started > with a simple script that does find and grep in .password-store, but > then I realized it's probably a better idea to integrate it to pass, > because: > 1) I want to be able to run "pass show" with and without --clip, with > and without the line number. I don't want to re-implement argument > parsing in my script. > 2) Such feature is probably useful for other people. Having it in the > main pass script is most convenient for users. I agree with both. Just I dont take time to put into pass itself. So as the excellent design of pass permit it, I hacked directly to the ~/.password-store ! ;-) I shared my code as is here: https://github.com/Sylvain303/find_pass Le 16/08/2016 à 03:18, David Adam a écrit : > On Sun, 14 Aug 2016, Kun Zhang wrote: >> However, I hate to type the full paths, because they are usually quite >> long. bash-completion is nice, but still kind of slows me down. The "find" >> command is not very helpful because I have to type out the full path in >> "show" even if there is only one match, and I cannot simply copy the "find" >> output to "show" because it's a tree view instead of plain paths. > Does your shell not do substring matching in completions for you? ;-) I manage both fullpath and pass argument, it seems that all idea here could merge into something really cool. Also it may be time to think about signed plugin as mentioned here: [pass] Extending pass with user-defined hooks / add ons https://lists.zx2c4.com/pipermail/password-store/2015-August/001659.html Hope that helps… Sylvain. -- Sylvain Viart - Consultant informatique système linux ___ Password-Store mailing list Password-Store@lists.zx2c4.com http://lists.zx2c4.com/mailman/listinfo/password-store
