Should we say goodbye to SecureString?

Dominick over at Least Privilege makes reference to the new functionality added to HawkEye which allows developers to display the contents of SecureString, and also change the current principal of the running thread. This looks like a really great debugging tool, and I'm thinking about paying the licensing fee to get a copy to play with it. At the same time, I think his implication that this now "breaks" SecureString is a bit alarmist.

Let's face it - all Security is "reversible", if it wasn't, it would be useless. So to imply we can't use SecureString because someone has figured out how to 'piece together' its memory, is overdoing it a little.

SecureString wasn't designed as a "SilverBullet" to secure all data. Like most security "defense in depth designs", it is meant as another 'step' , or 'speed bump' in making it more difficult to break into a system. Like most steps in a defense in depth architectures, each individual step can usually be broken when attacked in isolation (with enough time)

When you think about it, the potential 'hacker' in this scenario would need to have some fairly significant privileges in order to access the memory of the machine, and if that is the case, it's pretty much "game over" anyway.

The same holds true for the ability to "inject" new Principal objects into a thread. A potential hacker would need to have high proves to a machine, and have a fairly intimate knowledge of the application in order to pull this off (something I'll admit could certainly happen in a 'smart client' scenario).

I see this product as a great debugging and testing utility, and yes, another tool in a potential attacker's arsenal for breaking into a system.

Developers should continue to use SecureString, but understand the ways in which it can be "broken", and also the potential dangers when running their processes as Admin on the client. The key to protecting against this type of attack is not to stop using SecureString, but rather to run applications with least privilege, and potentially obfuscate Client code and Principal Names when using SmartClients