Using Secure String and Keeping it Secure [duplicate]

Question

This question already has an answer here:

• When would I need a SecureString in .NET? 11 answers

So the .NET framework provides the SecureString class for storing strings in a secure fashion. But to read the information and work with it you have to return it to a standard string. See this implementation example.

As you can see from the example using the pointer we return an unencrypted string. How to do we now manage that "insecure" instance of the string? What is the most secure way to work with the value once it has been set?

Edit

The purpose of this question was to discuss methods to REDUCE the surface area of potential attack when using SecureStrings and then working with the values. Not the "why" as to the "duplicate" link.

Answer 1

In placing the contents of a SecureString back into a String, you reintroduce the problems of using strings that are listed out here:

http://blogs.msdn.com/shawnfa/archive/2004/05/27/143254.aspx

With SecureString, there are options that are provided to marshal the contents into unmanaged memory so you can access the data and then dispose of the data when done with it.

These are options you just don't have with managed code. In working with unmanaged bytes, you can zero out the memory, make sure it's not paged to disk, etc, etc, which is exactly what you want to do to reduce the attack surface here.

The key here is to not make another instance of String and work with the data in a way where security is easier to manage when dealing with this data (which unfortunately, is unmanaged code right now).