It Doesn't Matter How They Get The Data

I was reading about using the SecureString class. This is a class that encrypts a string so that it is readable only on the current machine so that it does not hang around in plain text. Strings in C# are immutable, so they stick around until they are garbage collected, even if you set your reference to a string to String.Blank (""). The typical use is to collect the value from the user directly into a SecureString and shuttle it around on the current machine. As soon as it leaves the machine it must be turned back into a plain string, which is not a best practice.

I was looking into using SecureString in ASP.NET to handle a password. That password is passed in in plain text, and probably again when you actually use it, so there would be more than 0 instances in clear text in memory. Most StackOverflow answers point this out, but it would at least cut down on the number of instances as it is passed from method to method. Strings are a value type, meaning that every time you call another method with one as an argument .NET creates another copy.

In addition, I kept coming across the same kind of comment:

• From http://stackoverflow.com/questions/4463821/is-there-any-benefit-to-using-securestring-in-asp-net: "Since the hypothetical attacker would be using a server memory dump"
• From http://stackoverflow.com/questions/23775907/is-securestring-in-net-really-useful-for-web-application: "SecureString isn't useful against hackers who can read your application's memory. It only prevents accidental leaks via swap file, crash dump, etc"
• From http://stackoverflow.com/questions/26190938/is-securestring-ever-practical-in-a-c-sharp-application: "... it's unlikely for someone to gain this kind of access to your computer, but in the sense that if someone does gain this kind of access, the computer is considered (for all intents and purposes) compromised and I don't think there's any language or any technique you can use to defend against this completely" and "If an attacker already has the means for a heap inspection, then they most likely either (A) already have the means to read keystrokes, or (B) already physically have the machine"

Yeah, no one has ever been able to read a remote, web-accessible machine's memory. Until they could.

This reminded me of a comment a co-worker made about something you could do with a value from one of our databases: "How could anyone get it?"

It doesn't matter.

How did they get the Ashley Madison data? How did they get the Sony data? How did they get the U.S. Office of Personnel Management data?

It doesn't matter.

What matters is what more they can do with it. This is called "pivoting", or using one breach to hop a level deeper. Security through obscurity works until your whole database appears on the web. Any SQL system is one SQL injection vulnerability away from giving up everything. Any software involved in serving web requests is a buffer-overflow bug away from barfing memory.

Practice defense in depth to limit a small compromise from becoming much bigger.