1. 11
  1.  

  2. 3

    I’m using something similar and for me it’s quite convinient; I’ve set up a container-based encryption on an OpenBSD virtual machine on a remote server (based on softraid0). The passwords are stored there in plain text files and I use a script to mount the container and unmount it.

    When I need a password, I’m ssh'ing to the server (public key authentication, so I type the password only once for some time), I mount the container (so I type the password for the container here), and I grep for the proper file, copy/paste the password and unmount the crypto container, all by using simple bash 1-letter aliased commands.

    I’ve also set up an automatic backup script working once a week that additionally encrypts the whole container file with a generated password based on current date (the algorithm is in the backup script and in my head) and I’ve set up multiple scripts on some of my computers (laptop, desktop) to pull those backups, and push them to some other remote servers like google drive, so I know I won’t lose any password even if this remote server from some reason will go down, or my Internet access will be limited.

    1. 2

      copy/paste the password and unmount the crypto container

      There are other benefits to certain password managers, such as ones that fill in fields directly in your browser (e.g. the built-in FF password storage): it protects against clipboard / X selection monitoring and against certain side-channel attacks like Van Eck phreaking.

      The latter is a problem because, in order for you to copy the password to your clipboard, it is displayed on your screen. Then, in copying it, you expose your password in plaintext to a system that doesn’t benefit from the same security considerations as the system storing your password. A less sophisticated form of screen capture is also possible: malicious software simply capturing an image of the passwords you have on your screen.

      I store my passwords in one of two places (but not both): for general accounts, I store the password using FF’s (GNU IceCat, in my case) password manager with a strong master password. It uses 3DES for encryption (which is fine), but there’s reason for strong caution: FF is a large program with a huge attack surface; an encrypted file on disk using simple, standard, specialized tools is likely a better idea. The especially sensitive ones I store encrypted on disk. To mitigate the problems I mentioned, I copy the password to the clipboard by piping it to xclip as such:

      $ your-pw-cmd | xclip -i -l 1 -selection clipboard -quiet
      

      (You’ll need to use X11 forwarding over SSH.)

      -l 1 (“loop” 1) tells xclip to satisfy only one selection request before quitting, meaning that you can only paste the password once. So if an attacker queries the clipboard, xclip will exit, you won’t be able to paste your password, and you’ll know that your system was possibly compromised (at the very least, that you should change your password). -quiet causes xclip to run in the foreground so that you can see when (and that) it exits.

      When generating a new password, I pipe it directly to the file or, if using FF’s password manager, to the clipboard:

      # -l 2 so that I can paste it in the verification field as well
      pwgen -sy 64 | xclip -i -l 2 -selection clipboard -quiet
      

      This way, you avoid both selection monitoring and displaying the password on the screen, thereby avoiding screen capture (Van Eck or otherwise).

      If anyone has other suggestions for avoiding these attacks using standard tools, I’d love to hear your thoughts.

    2. 2

      I use emacs. Editing a file is as easy as emacs passwords.gpg

      1. [Comment removed by author]

        1. 9

          You are the next pdf.js vuln away from regretting that decision. :)

          1. 1

            Or the next time someone borrows their machine.

          2. 7

            It depends on the adversary.

            If you’re carrying around your laptop that you shut down frequently, and want to prevent someone from grabbing it and reading your disk, then an encrypted disk is helpful toward protecting your passwords.

            But often times your disk is already decrypted. If you suspend your laptop rather than shutting it down, for example, someone could potentially access your disk with a suitable exploit or by knowing your account password. A cold boot attack could be used if cracking is too difficult.

            But they might not need physical access: any software running on your system (given the appropriate permissions), if exploited, would be able to read your password file. It’s not a matter of trusting your software; I use a fully free GNU/Linux operating system and do generally trust the software I’m running and the communities behind them. But bugs exist, and it only takes one of them to potentially compromise data. If the box storing your passwords on executes any random program you download, that’s an even greater risk.

            If that box also runs your web browser, then you’re stepping into a minefield—it automatically downloads and executes arbitrary, untrusted programs (most often JavaScript) on your computer. If you take care to disable JavaScript and use other tools, great, but there could also be exploits elsewhere, like the image processor, or font renderer. It’s one thing to have software that has an unpatched CVE but is segregated from everything but the user; it’s another to have an unpatched browser (or a 0-day) that can be immediately exploited at any moment.

            If you don’t want to maintain another password, a simple GPG-encrypted file works well, since it’s a password you already know and use frequently (unless you don’t use GPG at all). If you use an editor like Emacs that transparently supports GPG-encrypted files, then it makes it all the easier. You then have a much smaller attack surface to worry about: an attacker would have to be able to access the data in memory as it’s being used, hope that it was swapped to disk (which some programs will prevent), trigger a coredump, etc.