Okay, maybe first a little context:

I use a PGP(GPG) encrypted file to hold my passwords. I use a (dash) script, bound to a key combination, to fill in usernames and passwords across applications/websites. I also have a PGP key pair for email.

I don't like having to give in my complex password to decrypt every e-mail every time. Luckily gpg2 solves this by caching the password with gpg-agent. However, I don't like this behavior when it comes to my password file. I don't want it decrypted for the same amount of time as my e-mails...

As far as I know, you can't set different timeouts for different keys, so I came up with the following solution:

To decrypt my password file I would use this line in my "auto-type" script:

store="$(gpg -q --batch --passphrase `dmenu -P` -d /path/to/file)"

(The -P option for dmenu is added with a patch. It doesn't show what you type. My password file would be symmetrically encrypted.)

This way, gpg-agent is circumvented and the password needs to be provided every time.

My question is: Would this jeopardize my password? Is this in any way less secure than giving gpg the password to gpg-agent?

Also, as you can see, I store the decrypted text in a local variable. How insecure is this? The script exits after typing (or not typing) the requested information and I have this trap at the beginning of the script:

finish () {
    unset store
    unset passw

trap finish EXIT

The best way to do so is using a file descriptor. From the manpage:

--passphrase-fd n
Read the passphrase from file descriptor n. If you use 0 for n, the passphrase 
will be read from stdin. This can only be used if only one passphrase is 
supplied. Don't use this option if you can avoid it.

This way you can be sure it is not visible on the command line or environment (which can be read via /proc by other processes as well).

  • Okay, so I have come up with dmenu -P | gpg --batch --passphrase-fd 0 -d /path/to/file. Would this hide the passphrase from the process table? It seems to me like it does (used the method described by David to test, even with grep [password]). (I deleted my previous comment.) – voyager Jan 20 '18 at 15:58
  • This should be safe. – allo Jan 21 '18 at 9:36

This depends on your threat model. If an attacker can get a process list (ps) on your machine at the right moment, they will see the substituted password being passed to GPG. This is available to a normal user, so also available to any malware on your system, even running as a different user.

You could see this by creating a FIFO for input (so it will block) and running ps aux after starting GPG. For example:

% mkfifo io
% gpg -q --batch --passphrase `echo supersecret` -d io &
% ps -ef | grep gpg
david    23136 22440  0 19:11 pts/4    00:00:00 gpg -q --batch --passphrase supersecret -d ./io

You can see that supersecret appears in ps output, just as your output of dmenu -P would be.

You should consider using --passphrase-file with redirection through a named pipe, such as:

gpg --passphrase-file <(dmenu -P)

This will transfer the passphrase through a pipe, rather than a command line argument, hiding it from any attacker able to read the process list.

Additionally, the stored data will be left in (physical) memory when the dash script exits, whether or not you unset the variable. (Unset just removes the reference to the variable.) There's a high likelihood that if someone physically took your machine and was able to dump memory, that memory forensics would lead to being able to extract some/all of your passwords. I am not aware of any shell or tool to mitigate this risk. (There's also a risk that it will be stored in swap, if you use swap. Consider ephemeral encrypted swap to mitigate this concern.)

  • Interesting... Exactly how could I see the password being passed? I tried running while :; do ps -eaf | grep gpg; donewhile doing gpg -q --batch --passphrase $(dmenu -P) -d /path/to/file, but I didn't find anything. Also, I can't use process substitution like <() in dash. Anything comparable I could do? I thought of FIFOs, but that seems even less secure than my initial idea, or am I wrong in this. Should I just use an established password manager like KeepassXC, instead of bothering with a PGP encrypted file? Your opinion? – voyager Jan 19 '18 at 3:04
  • I've added a section with an example of how it shows up in ps output. – David Jan 19 '18 at 3:14

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.