This post originated from an RSS feed registered with .NET Buzz by Sam Gentile. Original Post: Whidbey System.Security.SecureString Feed Title: Sam Gentile's Blog Feed URL: http://samgentile.com/blog/Rss.aspx Feed Description: .NET and Software Development from an experienced perspective - .NET/CLR, Rotor, Interop, MC+/C++, COM+, ES, Mac OS X, Extreme Programming and More! Latest .NET Buzz Posts Latest .NET Buzz Posts by Sam Gentile Latest Posts From Sam Gentile's Blog

Shawn Farkas blogs about the new SecureString class in Whidbey (I had missed this) and the reasons System.String for storing sensitive data is not secure:

• It's not pinned, so the garbage collector can move it around at will leaving several copies in memory
• It's not encrypted, so anyone who can read your process' memory will be able to see the value of the string easily.  Also, if your process gets swapped out to disk, the unencrypted contents of the string will be sitting in your swap file.
• It's not mutable, so whenever you need to modify it, there will be the old version and the new version both in memory
• Since it's not mutable, there's no effective way to clear it out when you're done using it

So instead of using a byte array, you can use Whidbey's new class SecureString. SecureStrings are held in encrypted memory by the CLR (using DPAPI), and are only unencrypted when they are accessed. Read more on his blog. I had missed this but it is definitely in my May Preview. Just one more way Whidbey is making your life a whole lot better.