9

The msdn documentation on PasswordBox.Password says:

When you get the Password property value, you expose the password as plain text in memory. To avoid this potential security risk, use the SecurePassword property to get the password as a SecureString.

So I send SecurePassword to my view model on PasswordChanged event, expecting everything to be secure, but if I inspect my application with Snoop, in PasswordBox's Password property I see the password I entered in plain text. Does that not kill the whole purpose of using SecurePassword? Is there anything else I should do here to protect the passwords?

Daria
  • 737
  • 7
  • 13
  • So, what property of your `PasswordBox` do you bind to the view model? – torvin Sep 24 '15 at 00:19
  • @torvin: I don't bind to PasswordBox. It has no bindable password properties due to security concerns, so, as I said, I handle the PasswordChanged event in code-behind. I just cast the DataContext to my view model type and update its password property. – Daria Sep 24 '15 at 14:15
  • You should bind your `PasswordBox.SecurePassword` property to a property of type `SecureString` in the view model. This way it will be secure against memory scans (which is what `SecureString` is for). – torvin Sep 24 '15 at 22:06
  • @torvin: My view model's password property is of type `SecureString`. – Daria Sep 24 '15 at 23:28

1 Answers1

6

This is my humble opinion.

Snoop injects its code in running application. So, it's basically a hacking tool. A very easy-to-use hacking tool, which works only with your GUI. This is why simply changing visibility of any item to hide some data from user is a poor secutity desicion. Everything about restrictions, access and security shouldn't be handled at UI layer. There are ways on How to Snoop proof your wpf application? but main point of answers there is that you have to design your application in the way, which doesn't allow snoop to violate anything. Validate everything on the server, for example.

Back to your question:

There are two scenarios. First one is: user creates a password. I believe this is not a concern, if a user or user's malware will see the password at this moment. Then you receive and store secured string. And clear user's password.

Second scenario: you display a stored password to user. The trick is - you don't display it. You know a length of a password, so you can display just disabled textbox with ****. And if a user wants to change a password - you give him actual passwordboxes, which he has to fill with old password and new one and we are back to scenario #1.

The silver lining is:

When a user inputs a password it's not a big deal, that it is lying in clear text somewhere in a memory, since a user knows what he've typed and malware can track keys pressed.

After you've stored the password you never ever give it back to user

Update: This is a source code for Password property of a Password box

   public string Password
        {
            [SecurityCritical]
            get
            {
                string password;

                using (SecureString securePassword = this.SecurePassword)
                {
                    IntPtr ptr = System.Runtime.InteropServices.Marshal.SecureStringToBSTR(securePassword);

                    try
                    {
                        unsafe
                        {
                            password = new string((char*)ptr);
                        }
                    }
                    finally
                    {
                        System.Runtime.InteropServices.Marshal.ZeroFreeBSTR(ptr);
                    }
                }

                return password;
            }

So, I guess what MSDN is saying, is that whenever you access Password property, by calling it in code (or viewing it in VS while debugging, or viewing it it Snoop) you call it's get method, which decrypts SecuredString to plain text, what exposes it to memory. If you don't call Password property and don't call it by inspecting in software tools, then password doesn't show up in memory in plain text.

Community
  • 1
  • 1
netaholic
  • 1,345
  • 10
  • 22
  • 1
    Does it mean that snooping the visual tree or intercepting keystrokes is considered much more difficult for malware than sniffing out the password string from memory? – Daria Sep 24 '15 at 13:18
  • 1
    @Andikki, I'm not an expert in developing malware, but something about words `considered much more difficult` confuses me. In PasswordBox MS secured password from appearing in memory as a plain text, unless you or someone else call its Password property. Could they have protected it more? Should they have? – netaholic Sep 24 '15 at 13:25
  • 1
    I don't know much about security, so my questions must be naive. Yet I want to make sure I'm implementing such a common element as authorization form right. Trying to understand why you should take precautions to not put your password in memory and at the same time should not be bothered by having an accessible password-revealing property. I can imagine a situation where a user sends a memory snapshot to support, unaware that he's leaking his password. Are we protecting against this kind of things here? – Daria Sep 24 '15 at 13:55