Securing Strings in Memory

[ERR!]
added by thbst16
9/12/2011 9:28:16 AM

2085 Views

I recently had the opportunity to look into and make use of the Microsoft System.Security.SecureString class. This class is one of those dark corners of the .NET Framework that you don’t think about on a day-to-day basis but are really glad that it’s there when your security auditor starts asking questions about how PII data such as social security numbers are protected while resident in memory. The SecureString class takes care of this problem, helping you avoid a situation where unencrypted sensitive String data is left lingering around on the .NET heap. However, since this class does reference unmanaged memory buffers, its use is not entirely intuitive. I’ve attempted to demystify things with the explanation, drawing and code snippets in this post.

Read the full story
Security
3 comments
dpeterson
9/12/2011 9:27:51 AM
I've never heard of the SecureString class, and it's unfortunate that that is the case. I think with Microsoft's new outlook on the importance of security, they should be promoting these features and baking them into more of the framework.

I read through the SecureString class docs, as well as the article on DPAPI, and I can't find where it determines what encryption algorithm to use. I would hope that it's using AES, but as a developer I'm curious as to whether the encryption scheme can be chosen? This is important if requirements change and require a higher grade of encryption in the future, or if a vulnerability is found in the encryption mechanism that DPAPI is choosing.
thbst16
9/12/2011 9:39:28 AM
I think DPAPI uses a proprietary MS encryption algorithm, which is never a good thing. I'm not sure what support the native Windows APIs provide for public algorithm-based symmetric-key encryption. This may ultimately be the limiting factor here.
dpeterson
9/12/2011 10:56:21 AM
Encryption and proprietary are never good together ;-)
Unfortunately, they've shot themselves in the foot on this feature if that's the case. I'm pretty sure that credit card companies require AES encryption, so this implementation could not be used in that case.