0

I have a property that holds a personal information. I am trying to figure out the best approach to guard against any kind of Privacy Violation: Heap Inspection. This is what I have so far:

private static SecureString _testPI;

public static string TestPI
{
      get
      {
            return ConvertToString(_testPI);
      }
      set
      {
            _testPI= ConvertToSecureString(value);
      }
}

As you can see I have two methods ConvertToString and ConvertToSecureString. As the methods name points out they convert a string taken from the user or database and converts it to a SecureString, then converted back to a regular string when the property is called.

Also when the class is instantiated I do whatever I need to do with the class then set the instance to null.

TestClass myTest = new TestClass();
myTest.TestPI= testString;

ValidatePI(myTest.TestPI);
myTest = null;

Is this best practice?

I am using .NET framework 4.5.1

Hemi81
  • 578
  • 2
  • 15
  • 34
  • 1
    What scenarios are you wanting to protect against? If someone has enough access to inspect your heap, they can probably hook into enough system calls to see `SecureString`s going to/from unmanaged memory too. – James Thorpe Nov 08 '16 at 12:29
  • Take the scenario where you are just validating that the data is good and falls within length restrictions and formats. – Hemi81 Nov 08 '16 at 12:35
  • 1
    That's what your program is _doing_. What _attack scenarios_ are you worried about? In general, if your data is _ever_ in managed memory, ie as a `String`, using `SecureString` isn't going to help protect it. – James Thorpe Nov 08 '16 at 12:40
  • Well maybe if user has to specify this information once, then send it right away to your server. Keep it for the smallest amount of time in your code as you can. Later when you want to reuse it, download it from a server as an already decrypted string. – FCin Nov 08 '16 at 12:40
  • @JamesThorpe but what if you got a crash dump, sent it to the developer for inspection and that developer sees all password there in plain? SecureString is more to protect from such kind of scenarios. – Evk Nov 08 '16 at 12:47
  • @Evk Indeed - that's one scenario where it is useful. But not if it's been held in a `String` beforehand - there's no telling how long it will be around for in memory before the GC kicks in. If you're converting `SecureString` to/from `String`, you're probably Doing It Wrong. – James Thorpe Nov 08 '16 at 12:48
  • 2
    Yes sure, as used in question it's completely useless. I suggest author to read this question and answers to it: http://stackoverflow.com/q/26190938/5311735 – Evk Nov 08 '16 at 12:52
  • @Evk yes this type of scenario 'crash dump' is what I am talking about. Would it still be effective to handle the value given the current solution? – Hemi81 Nov 08 '16 at 12:53
  • @Evk thanks for the link. I know it makes sense to have the PI in SecureString as much as possible. Yes, it will eventually be a string at some point, but no software is impenetrable. Just try and limit access where I can. – Hemi81 Nov 08 '16 at 12:58
  • 3
    Actually you should try to NOT convert it to string, but instead use it as char array. See here for an example: https://jhatax.blogspot.ru/2009/10/safely-using-securestring-in-c-dont.html – Evk Nov 08 '16 at 13:01

0 Answers0