.Net 3.5, most secure way to pass string between processes

I'd like to be able to pass a SecureString (a cached passphrase) to a child process in C# (.Net 3.5), but I don't know what the most secure way is to do it. If I were to convert the SecureString back to a regular string and pass it as a command-line argument, for example, then I think the value may be prone to disk paging--which would make the plaintext touch the filesystem and ruin the point of using SecureString.

Can the IntPtr for the SecureString be passed instead? Could I use a named pipe without increasing the risk?

From stackoverflow C. Lawrence Wenham

• Marshal.SecureStringToBSTR within the System.Runtime.InteropServices namespace is probably what you're looking for.

  edit Sorry, you're right. That's not the ticket.

  Alternatively, you can use asymmetric cryptography to encrypt your string before passing it.

  From Will

• Will,

  That will convert the SecureString back into a regular string, which I know, but the question is how to pass it to a child process the most secure way possible.

  From C. Lawrence Wenham

• Unless your child process also understands how to work with SecureString I don't think there is a way to pass it directly. For example, the Process.Start() method has two overloads that take a SecureString so the risk of the actual string value being sniffed is minimized (it's still possible since somewhere along the the way the actual value has to be retrieved/unmarshalled).

  I think a lot of how to do this will depend on what the child process is and how it is being started.

  From Scott Dorman

• Scott, the child process is another .Net 3.5 program that I've written, so the option is there to have it use almost any mechanism.

  The SecureString parameter for Process.Start() appears to be for the password when starting the process as another user. It doesn't get passed, or is accessible to the process itself, it's consumed by the OS to log-in to the alternate user account.

  From C. Lawrence Wenham

• In general you should define your threat model before worrying about more exotic attacks. In this case: are you worried that somebody shuts down the computer and does a forensic analysis of the harddrive? Application memory can also be swapped out, so the simple fact that one process has it in memory, makes it potentially possible for it to end in the swap file. What about hibernation? During hibernation the entire content of the memory is written to the harddisk (including the SecureString - and presumably the encryption key!). What if the attacker has access to the system while it's running and can search through the memory of applications?

  In general client side security is very tricky and unless you have dedicated hardware (like a TPM chip) it is almost impossible to get right. Two solutions would be:

  • If you only need to test for equality between two strings (ie: is this string the same as the one I had earlier), store only a (salted) hash value of it.
  • Make the user re-enter the information when it is needed a second time (not very convenient, but security and convenience are opposed to each other)
  From Cd-MaN