WPF PasswordBox and Data binding

Like Charles Petzold, I am something of a Xamlholic: I'll try for hours to find a way of expressing my UI in pure XAML, rather than pollute its purity with C# code, even if the code could go in a code-behind file. This addiction is largely driven by WPF's fantastic support for Data Binding which lets anything in the UI be data-bound to anything else. Well, almost anything in the UI. Just occasionally I find myself having to fall back on property setters and getters, poking data into controls then sucking it back again, the way Windows Forms made me earn my living. One control which nearly had me beat was PasswordBox.

PasswordBox is what you need whenever you want to mask the characters as a user types them: for some reason, WPF's standard TextBox doesn't support that scenario. Now PasswordBox has, as you'd expect, a Password property that allows you to get and set the password. However, it's a plain CLR property rather than a Dependency Property, so it doesn't support being the target of a Data binding.

Ben Westbrook of Microsoft explains in a forum post that it was not exposed as a Dependency Property for security reasons. The values of Dependency Properties are managed centrally by the Dependency Property sub-system so that it can handle all the data-binding and cool animation stuff (animating a password - now that would be interesting!); the consequence of this is that the data effectively becomes public property. With something as sensitive as a password it's reasonable that a control (like PasswordBox) would want to keep the data closer to its chest. So internally the PasswordBox stores the password in a good old field, and in fact holds it using a SecureString - a string that is automatically encrypted in memory and obliterated when no longer needed; if you Reflector PasswordBox you'll see that the Password property setter stuffs any value you set into a SecureString, and the getter reads it out for you; PasswordBox appends characters one by one to the SecureString as you type them, so the password is never stored as clear text until you retrieve it through the Password property.

As an aside, one thing I don't understand about the design is why PasswordBox doesn't provide a property to access the password as a SecureString, and so preserve the encryption? The act of retrieving the password through the Password property (as you'll have to do at some point in order to use the password) will turn it into clear text, and then you'll surely loose most of the benefit of ever having it encrypted? Perhaps someone from Microsoft can explain?

Update: As Ray pointed out in the comments, Microsoft have now (as from .Net 3.5 SP1) added a SecurePassword property to PasswordBox; it's still not a DependencyProperty though.

Anyhow, let's get to the point. Sometimes your main interest in using a PasswordBox is to have the password text masked as it's typed, and encryption isn't really an issue. In this case its a shame not to be able to use data binding.

Fortunately, WPF has the concept of Attached Properties that allow controls to be extended very easily. I've knocked up a class that extends PasswordBox with an Attached Property that lets you data bind the password. You use it as shown below (note particularly the additional xmlns element you need to add to the root element in your XAML):

<Page xmlns:ff="clr-namespace:FunctionalFun.UI">
  <!-- [Snip] -->
  <PasswordBox x:Name="PasswordBox"
      ff:PasswordBoxAssistant.BindPassword="true"  ff:PasswordBoxAssistant.BoundPassword="{Binding Path=Password, Mode=TwoWay, UpdateSourceTrigger=PropertyChanged}">

</Page>

And here's the code. Very simple; setting the BindPassword property causes the code to start listening to the PasswordChanged event on the PasswordBox: whenever there is a change the code pushes the new value into the Attached Property BoundPassword which you can specify a binding for. It also takes care of the other direction, going from BoundPassword (whenever your the bound source property changes) into the PasswordBox. The only complication is making sure the whole thing doesn't get recursive and blow up: that's what the private attached property UpdatingPassword is for.

using System.Windows;
using System.Windows.Controls;

namespace FunctionalFun.UI
{
  public static class PasswordBoxAssistant
  {
      public static readonly DependencyProperty BoundPassword =
          DependencyProperty.RegisterAttached("BoundPassword", typeof(string), typeof(PasswordBoxAssistant), new PropertyMetadata(string.Empty, OnBoundPasswordChanged));

      public static readonly DependencyProperty BindPassword = DependencyProperty.RegisterAttached(
          "BindPassword", typeof (bool), typeof (PasswordBoxAssistant), new PropertyMetadata(false, OnBindPasswordChanged));

      private static readonly DependencyProperty UpdatingPassword =
          DependencyProperty.RegisterAttached("UpdatingPassword", typeof(bool), typeof(PasswordBoxAssistant), new PropertyMetadata(false));

      private static void OnBoundPasswordChanged(DependencyObject d, DependencyPropertyChangedEventArgs e)
      {
          PasswordBox box = d as PasswordBox;

          // only handle this event when the property is attached to a PasswordBox
          // and when the BindPassword attached property has been set to true
          if (d == null || !GetBindPassword(d))
          {
              return;
          }

          // avoid recursive updating by ignoring the box's changed event
          box.PasswordChanged -= HandlePasswordChanged;

          string newPassword = (string)e.NewValue;

          if (!GetUpdatingPassword(box))
          {
              box.Password = newPassword;
          }

          box.PasswordChanged += HandlePasswordChanged;
      }

      private static void OnBindPasswordChanged(DependencyObject dp, DependencyPropertyChangedEventArgs e)
      {
          // when the BindPassword attached property is set on a PasswordBox,
          // start listening to its PasswordChanged event

          PasswordBox box = dp as PasswordBox;

          if (box == null)
          {
              return;
          }

          bool wasBound = (bool)(e.OldValue);
          bool needToBind = (bool)(e.NewValue);

          if (wasBound)
          {
              box.PasswordChanged -= HandlePasswordChanged;
          }

          if (needToBind)
          {
              box.PasswordChanged += HandlePasswordChanged;
          }
      }

      private static void HandlePasswordChanged(object sender, RoutedEventArgs e)
      {
          PasswordBox box = sender as PasswordBox;

          // set a flag to indicate that we're updating the password
          SetUpdatingPassword(box, true);
          // push the new password into the BoundPassword property
          SetBoundPassword(box, box.Password);
          SetUpdatingPassword(box, false);
      }

      public static void SetBindPassword(DependencyObject dp, bool value)
      {
          dp.SetValue(BindPassword, value);
      }

      public static bool GetBindPassword(DependencyObject dp)
      {
          return (bool)dp.GetValue(BindPassword);
      }

      public static string GetBoundPassword(DependencyObject dp)
      {
          return (string)dp.GetValue(BoundPassword);
      }

      public static void SetBoundPassword(DependencyObject dp, string value)
      {
          dp.SetValue(BoundPassword, value);
      }

      private static bool GetUpdatingPassword(DependencyObject dp)
      {
          return (bool)dp.GetValue(UpdatingPassword);
      }

      private static void SetUpdatingPassword(DependencyObject dp, bool value)
      {
          dp.SetValue(UpdatingPassword, value);
      }
  }
}

Update: If you're trying to weigh up the security risks of using this method, take a look at Daniel D'Agostino's article where he shows how passwords in memory can be snooped.