4

I'm on a Windows 2003 server and I need to write a batch file to automate decryption using GnuPG. The decryption command requires a passphrase to use the private key.

Here are some workable options that don't entirely satisfy me :

  1. echo thisIsMyPassphrase|gpg.exe --passphrase-fd 0 --output %1 --decrypt %2 Such an hardcoded passphrase doesn't look like a secure approach ! Also, it is not convenient to change (as directly embeded within the .cmd file).

  2. Store the passphrase in a distinct file and make sure only the windows user running the decryption process can access it (using NTFS security settings).
    gpg.exe --passphrase-file X:\passphrase.txt --output %1 --decrypt %2
    What I don't like much here.. is that we'd have a naked file somewhere just containing this highly sensitive information. odd to maintain ? easy to find ? ..

  3. I don't feel like storing the passphrase in an environment variable sounds good (looks quite exposed)..
    echo %MY_PASSPHRASE%|gpg.exe --passphrase-fd 0 --output %1 --decrypt %2


Well, what's you opinion about the best (or "least bad") solution to achieve this ?

Myobis
  • 1,258
  • 14
  • 26
  • 1
    Regarding #2, the file name could actually be another parameter and the file could be kept e.g. on a USB flash drive. But the error message would still have to be dealt with, of course (can't help with that, I'm afraid). – Andriy M Jun 04 '12 at 10:22
  • For #2, I was thinking about storing the Passphrase.txt in another server of the network.. so that the automation stuff physically on the decryption server isn't enough to decrypt (in case of a physical thief of the server). In my case, using removable drives doesn't really solves this issue (as they are physically attached to the server) and we have quite limited physical accesses to the server room. – Myobis Jun 04 '12 at 10:40
  • 1
    Storing on a separate server opens a new attack vector, however. Someone able to sniff network traffic may be able to get the password that way. – Eric J. Sep 16 '13 at 16:01

1 Answers1

0

I think your second (password file) option seems to be a fairly reasonable approach for the majority of use cases. And using the Windows 2003 Encrypted filesystem may mitigate some level of concern about physical server theft. You can certainly jump through hoops to further obfuscate the password, but it would be just that - obfuscation. Your true security lies within the NTFS filesystem security.

It almost laughable to mention, but with the "proper" security implementation being a balancing act between solution cost and data value, if the data is sensitive enough and you're willing to throw some cash at the problem there are hardware security modules (nCipher comes to mind) that might be able to assist with this type of problem.

Here's a link to a similiar SO discussion if you're interested: Storing passwords for batch jobs

Community
  • 1
  • 1
xelco52
  • 4,943
  • 4
  • 35
  • 55