3

My custom .Net process maps a drive with a different account than the current context. The password is stored in the config file, DPAPI encrypted with the machine key.

The code works, but I'm wondering if usage of SecureString would offer additional security. I believe the weakness below lies with the PlainBytes array and the MapPwd and MapDriveCmd strings when they are in memory in plain text.

I've done some research on SecureString, but don't quite understand if it applies here. The three local suspect variables aren't used after the code below. If I keep it as is without SecureString, will the garage collector dispose of these before the process ends?

byte[] CipherBytes = Convert.FromBase64String(ConfigurationManager.AppSettings.Get("MapPwd").Trim());
byte[] PlainBytes = ProtectedData.Unprotect(CipherBytes, null, DataProtectionScope.LocalMachine);
string MapPwd = System.Text.Encoding.UTF8.GetString(PlainBytes);

string MapDriveCmd = "/C net use " + MapLetter + " " + MapPath + " " + MapPwd + " /USER:" + MapUser + " /PERSISTENT:NO";
System.Diagnostics.Process MapDrive = System.Diagnostics.Process.Start("CMD.exe", MapDriveCmd);
MapDrive.WaitForExit();

Any additional comment on the technique in general is welcome. Thanks.

user640118
  • 803
  • 2
  • 13
  • 25

1 Answers1

0

Using SecureString is not going to be very beneficial in your case.

The purpose of SecureString is to provide a way for data to be garbage collected when no longer needed, so that the data doesn't linger in RAM. If the data was kept around, someone could use a debugger (or other similar method) to inspect the processes allocations and potentially get the result.

DPAPI simply isn't very secure. It's not bad...but it's a reversible algorithm. It's far better to use one-way hashing algorithms. However, you cannot do that in this use case. Since you're using DPAPI, any other user of the PC probably has the ability to read your config file. If they can read the config file, and since you're using the machine key, that use can easily decrypt your password by simply calling ProtectedData.Unprotect()

To make this more secure, don't use passwords. If possible, grant permission to an AD machine account or managed service account.

Jared Dykstra
  • 3,596
  • 1
  • 13
  • 25
  • And if you do use a one-way algorithm, [don't forget the salt](http://stackoverflow.com/q/420843/15880). (side note: don't use md5 like the linked example, sha256 should be bare minimum these days, if not sha512... the bcrypt library might help a bit) – Powerlord Nov 13 '15 at 20:49
  • I tried to use the user key for the data protection scope, which I think would be more secure, but I could not get it working. The process is called from a Windows Scheduler Task, running as an AD service account (and different than the drive map account) Thanks for the info! – user640118 Nov 13 '15 at 21:07