13

I've read that the password in a WPF PasswordBox does not have a dependency property for binding the password for security reasons. Despite this, there are ways to bind it anyway.

Users of the MVVM pattern require this databinding; the viewmodel cannot touch the PasswordBox directly without breaking the pattern. One way to work with PasswordBoxes in an MVVM setting is to pass the entire PasswordBox control to the ViewModel, but this breaks the pattern anyway. Binding the Password is probably the cleanest way to work with passwords using MVVM.

There is an argument against binding the Password since this would keep the plaintext password in unencrypted memory until it gets garbage collected. The way I see it, however, is that the password gets stored in unencrypted memory anyway from the moment you access the Password property. This view (or similar) seems to be seconded in this question. Of course it would be in memory for a shorter period without binding (not that login forms have a tendency of being long-lived anyway), but the risk is still there.

Given these arguments, is it really a bad idea to bind the password? And why?

Community
  • 1
  • 1
Gigi
  • 28,163
  • 29
  • 106
  • 188
  • Did you consider binding to the getter of the Password property instead? It keeps the mvvm pattern intact – Gayot Fow Apr 12 '14 at 14:27
  • How do you mean? What getter? – Gigi Apr 12 '14 at 14:29
  • 1
    +1: Interesting question. My concern is that unencrypted passwords can remain in memory indefinitely, even if they are held in short-lived variables; .NET does not scrub reclaimed memory during garbage collection. Thus, unless you're using `SecureString` throughout your implementation (up to the computation of the password's hash), I see little advantage in maintaining this level of security, and would just go with the attached property suggested in your first link. – Douglas Apr 12 '14 at 15:03
  • @Gigi, the getter of the password property – Gayot Fow Apr 12 '14 at 15:24
  • +1. In my opinion, it is not a bad idea. For me, it seems to be just a kind of micro-optimization hoping this might improve security. If some kind of attacker is able to read your memory, you might have other worries than simple passwords, for example how he gained access and how you need to clean up the whole mess (network, firewall, anti-virus, etc). I assume there is not much advantage. – Zwirbelbart Apr 12 '14 at 16:08
  • 1
    @Zwirbelbart a valuable sort of "micro-optimization". Perhaps my application responds to SSL pings, then the Heartbleed bug let bad guys read from part of its memory, but without much control over what it reads. It would be nice to know that I don'd have unneeded password strings floating about. – Adrian Ratnapala Apr 14 '14 at 07:43
  • @Adrian Ratnapala I think it is very exaggerated to think about attacks like heartbleed. I never heard such an explanation when it comes to sensitive data that lays in your memory. Something like heartbleed seems very unlikely to happen, in my opinion. But okay, that's of course a point you can argue about. – Zwirbelbart Apr 14 '14 at 13:50

2 Answers2

6

Using tools like WPF Inspector or Snoop you can spy the password string. An alternative to passing the PasswordBox to the view-model is to attach a Behavior<UIElement> object to your PasswordBox object like below:

public sealed class PasswordBoxBehavior : Behavior<UIElement>
{
    protected override void OnAttached()
    {
        base.OnAttached();
        AssociatedObject.LostKeyboardFocus += AssociatedObjectLostKeyboardFocus;
    }

    protected override void OnDetaching()
    {
        AssociatedObject.LostKeyboardFocus -= AssociatedObjectLostKeyboardFocus;
        base.OnDetaching();
    }

    void AssociatedObjectLostKeyboardFocus(object sender, KeyboardFocusChangedEventArgs e)
    {
        var associatedPasswordBox = AssociatedObject as PasswordBox;
        if (associatedPasswordBox != null)
        {
            // Set your view-model's Password property here
        }
    }
}

and the XAML code:

<Window ...
        xmlns:i="clr-namespace:System.Windows.Interactivity;assembly=System.Windows.Interactivity">
    ...
    <PasswordBox ....>
        <i:Interaction.Behaviors>
            <local:PasswordBoxBehavior />
        </i:Interaction.Behaviors>  
    </PasswordBox>
    ...
</Window>
mca
  • 466
  • 3
  • 11
  • 1
    You're right - it is indeed possible to snoop passwords if they're bound. For me this means that the answer is definitely: yes, it is a very bad idea to bind passwords. – Gigi May 23 '14 at 12:20
  • 1
    You can snoop the Password property of the PasswordBox, too. Not binding it doesn't solve the problem... – almulo Jun 04 '15 at 12:39
  • The ideea is to avoid using Password property for password. Better use the SecurePassword property which can't be snooped. – mca Jun 11 '15 at 05:48
2

Not binding the password box thinking snooping it will not yield the results is not wise to think!.

Passwordbox.Password will still show the password no matter what![enter image description here]1

enter image description here

OptimusPrime
  • 51
  • 5