.Net 4 beta 2 and SecureString

[localzuk]

I am working on making a small piece of software to stick online for those who want it, and one of the things I need it to do is get credentials, with the possibility of storing them (securely), and then use those credentials to send emails.

So, I've now worked through most of it, and have a nearly working program. The giant issue that remains is a simple one. The password that is entered gets stored in the relatively new object type of 'SecureString' rather than as a normal string. This is a good thing.

The problem arises when I then want to pass that string to the SMTP server - which calls for a NetworkCredential object for authentication. This object only allows normal strings.

I have 2 choices. First one, use the joyfully insecure piece of code below and then have it in memory as a normal string anyway.

        static String SecureStringToString(SecureString value)
        {
            IntPtr bstr = Marshal.SecureStringToBSTR(value);

            try
            {
                return Marshal.PtrToStringBSTR(bstr);
            }
            finally
            {
                Marshal.FreeBSTR(bstr);
            }
        }

or the second option - use the .Net 4 Beta release, which has SecureString support in the NetworkCredential object. The release date for the full version of .Net 4 is March 22nd 2010, so it wouldn't be a huge amount of time, but it would still be me using a pre-release version of .Net.

So, what would you do?

[PiqueABoo]

Live with it like everyone else does? I wouldn't put anything into production that uses a beta dotNet, and I'd make that finally section call Marshal.ZeroFreeBSTR(bstr)

[localzuk]

I've decided to simply wait until March. Then I'll update to Visual Studio 2010 and .Net 4.

Fiddling with Marshalling etc... just makes what should be, relatively, secure completely insecure.

[PiqueABoo]

just makes what should be, relatively, secure completely insecure.

Secure from what?

If the answer is to some password stealing malware, then all the best malware gets admin and whatever security you decide to add, as admin it can get past that one way or another.

Perspective: That password has got to pop out as plaintext in memory somewhere: a) Completely in MS-land where we assume it will be well looked after is a bit better than b) very briefly and cautiously in your code, but that in turn is much better than c) sitting around as plaintext for ages in your code or anywhere else.