Is SecureString ever practical in a C# application?

Feel free to correct me if my assumptions are wrong here, but let me explain why I’m asking.

Taken from MSDN, a SecureString:

Represents text that should be kept confidential. The text is encrypted for privacy when being used, and deleted from computer memory when no longer needed.

I get this, it makes complete sense to store a password or other private information in a SecureString over a System.String, because you can control how and when it is actually stored in memory, because a System.String:

is both immutable and, when no longer needed, cannot be programmatically scheduled for garbage collection; that is, the instance is read-only after it is created and it is not possible to predict when the instance will be deleted from computer memory. Consequently, if a String object contains sensitive information such as a password, credit card number, or personal data, there is a risk the information could be revealed after it is used because your application cannot delete the data from computer memory.

However, in the case of a GUI application (for example, an ssh client), the SecureString has to be built from a System.String. All of the text controls use a string as its underlying data type.

So, this means that every time the user presses a key, the old string that was there is discarded, and a new string is built to represent what the value inside the text box is, even if using a password mask. And we can’t control when or if any of those values are discarded from memory.

Now it’s time to log in to the server. Guess what? You need to pass a string over the connection for authentication. So let’s convert our SecureString into a System.String…. and now we have a string on the heap with no way to force it to go through garbage collection (or write 0’s to its buffer).

My point is: no matter what you do, somewhere along the line, that SecureString is going to be converted into a System.String, meaning it will at least exist on the heap at some point (without any guarantee of garbage collection).

My point is not: whether there are ways of circumventing sending a string to an ssh connection, or circumventing having a control store a string (make a custom control). For this question, you can replace “ssh connection” with “login form”, “registration form”, “payment form”, “foods-you-would-feed-your-puppy-but-not-your-children form”, etc.

• So, at what point does using a SecureString actually become
  practical?
• Is it ever worth the extra development time to completely eradicate
  the use of a System.String object?
• Is the whole point of SecureString to simply reduce the amount of time a System.String is on the heap (reducing its risk of moving to a physical swap file)?
• If an attacker already has the means for a heap inspection, then he most likely either (A) already has the means to read keystrokes, or (B) already physically has the machine… So would using a SecureString prevent him from getting to the data anyways?
• Is this just “security through obscurity”?

Sorry if I’m laying the questions on too thick, curiosity just got the better of me. Feel free to answer any or all of my questions (or tell me that my assumptions are completely wrong). 🙂