PasswordBox binding issue MVVM

Question

I have come across the problem of password box binding. My application follows MVVM. When I tried to search google to find out how to solve the issue of password box binding, I found two kinds of solution - 1> Use of attached properties 2> Use of Secure strings (http://www.griffinscs.com/blog/?tag=mvvm). Since the second option seemed to be more secure, I was inclined to choose this option. But latter I found out that I can extract the actual string within the secure string using the following code

IntPtr iPtr = Marshal.SecureStringToBSTR(securePassword);
// securePassword is of SecureString type

string str = Marshal.PtrToStringUni(iPtr);

Now I am little confused. Please help me to understand the folowing issues 1> Is use of Secure string is really better than use of String ? 2> Which one of the above two is the right option when I am following MVVM pattern and at the same time I want password strings to be secure.

Answer 1

Is use of Secure string is really better than use of String

Yes and no. SecureString gives you an option in how you keep your secret strings in memory. They help prevent naughty people with debuggers examining the memory contents of an application looking for secrets, and they also offer a better guarantee around disposal than a regular string. But it also has to be said that they are a PITA to use and very little of the framework actually uses them at the moment. This previous SO answer may give you a good indication of their benefits.

Which one of the above two is the right option when I am following MVVM pattern and at the same time I want password strings to be secure

At some stage you will need to use the password. It is hard to get at the contents of a SecureString - it's meant to be secure. But how do you take the contents and store that password into your database so that you can compare future logins against it? The answer is the SecureString doesn't solve this problem - you still need to extract the real string before you salt and hash it and store it. If the password being entered is for creating an X509Certificate2 and you will never store it then use the SecureString.

So, the answer is....
Use a regular string where you need to access the contents of the string yourself, and use a secure string where the framework method or API function requires it.

This means that if you are going to use the PasswordBox in the UI then you will need to get access to the unencrypted contents so that you can either store it or comapre it against a previously stored entry.