views:

127

answers:

5

I'm working on a .NET Windows application that will use Process.Start to launch another internally developed .NET application running on the same PC. I need to pass database connection information, including a user ID and password, to the target application. I'm trying to determine whether I need to encrypt the information before I send it.

Assuming the end user's PC isn't compromised, will the connection information be exposed anywhere if I pass it unencrypted in the arguments?

Would something like this be OK...

string myExecutable = "myApp.exe";
string server = "myServer";
string database = "top_secret_data";
string userID = "myUser";
string password = "ABC123";
string dbInfo = string.Format("server={0} database={1} userID={2} password={3}", server, database, userID, password);
ProcessStartInfo startInfo = new ProcessStartInfo(myExecutable, dbInfo);
Process.Start(startInfo);

Or should I use something like this...

var crypto = new MySymmetricCryptoLib.Crypto();
string myExecutable = "myApp.exe";
string server = crypto.Encrypt("myServer");
string database = crypto.Encrypt("top_secret_data");
string userID = crypto.Encrypt("myUser");
string password = crypto.Encrypt("ABC123");
string dbInfo = string.Format("server={0} database={1} userID={2} password={3}", server, database, userID, password);
ProcessStartInfo startInfo = new ProcessStartInfo(myExecutable, dbInfo);
Process.Start(startInfo);
+4  A: 

Retrieving the arguments that a process was called with is quite easy, so they'll be exposed locally to a technically-minded user. If that's not a problem for you, then I wouldn't worry about it, since you say you're not transmitting over the network and your question asks us to assume the machine's not compromised.

John Feminella
+2  A: 

It's not clear from your question from whom you are trying to protect the data. It's confusing because you said "assume the PC is not compromised".

If you are starting a local process on the machine and the machine is not compromised then what is there to protect from? Nothing will traverse the network in this scenario so no one can spy on the arguments.

However, if you're worried about anyone who may have administrative access to the computer or the user potentially seeing the data, then yes you must encrypt it. It's fairly easy to see the command line arguments of a process. Any semi-competent user could find them.

JaredPar
Good point. To clarify, I didn't have a specific "from whom" in mind. I just wanted to gauge the general risk of passing this data unencrypted, and see under what types of circumstances the data could be exposed.
John M Gant
A: 

As you'd have to modify the receiving app to do the decryption, why not modify the receiving app to read from a config file, then encrypt the config file. If you need to pass different values to the other app, why not pass a connectionString key?

RichardOD
Good question. I didn't specify this in the question, but the connection information is very variable. It depends on the user and environment.
John M Gant
Can you not therefore encapsulate this logic in the second app?
RichardOD
That would generally be a good idea, but for reasons I can't explain here, that's not an option in this case.
John M Gant
+1  A: 

I would encrypt the entire string not the individual pieces, you've basically told a mischevous user hey here's the connection information just go ahead and break it. Another option would be to pass the arguments once the other application has started.

It's important when your building security measures to identify what the attack is (Gaining access to the connection information for the database), and who is going to be issuing the attack. Are you trying to prevent a local user from getting this? Are you trying to prevent a normal user or an expert user?

For example an expert could go ahead and dump the memory of the process, and find he unencrypted string.

JoshBerke
+1  A: 

Use a named pipe and set the ACLs on it appropriately, then have the child process inherit the handle - don't worry about encryption.

Paul Betts