C# WPF/MVVM: Why You Shouldn't Bind PasswordBox Password

Hi! :)

In WPF circles, the PasswordBox control has generated quite a bit of discussion. The thing is that you can access the password entered by the user using the Password property, but it's not a dependency property, and MVVM purists don't like the fact that they can't bind it to their ViewModel.

In this article, I'm going to show how the password can be bound in the ViewModel despite this limitation. And I'm also going to show you why it's a very bad idea to do this. This article is a little advanced in nature, and assumes you're familiar with WPF and MVVM.

Right, so let's set up something we can work with. Create a new WPF application, and then add a new class called MainWindowViewModel. In your MainWindow's codebehind (i.e. MainWindow.xaml.cs), set up your window's DataContext by adding the following line at the end of your constructor:

            this.DataContext = new MainWindowViewModel();

Right, now let's add a couple of properties to our MainWindowViewModel that we'll want to bind to:

        public string Username { get; set; }

        public string Password { get; set; }

Now we can build our form by editing the XAML in MainWindow.xaml. Let's go with this (just make sure the namespace matches what you have):

<Window x:Class="CsWpfMvvmPasswordBox.MainWindow"

        xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"

        xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"

        Title="Login"

        Height="120"

        Width="325">

    <Grid>

        <Grid.RowDefinitions>

            <RowDefinition Height="20" />

            <RowDefinition Height="20" />

            <RowDefinition Height="30" />

        </Grid.RowDefinitions>

        <Grid.ColumnDefinitions>

            <ColumnDefinition Width="90" />

            <ColumnDefinition />

        </Grid.ColumnDefinitions>

        <TextBlock Text="Username:"

            Grid.Row="0"

            Grid.Column="0"

            Margin="2" />

        <TextBox Text="{Binding Path=Username}"

            Grid.Row="0"

            Grid.Column="1"

            Margin="2" />

        <TextBlock Text="Password:"

            Grid.Row="1"

            Grid.Column="0"

            Margin="2" />

        <PasswordBox Password="{Binding Path=Password}"

            Grid.Row="1"

            Grid.Column="1"

            Margin="2" />

        <Button Content="Login"

            Grid.Row="2"

            Grid.Column="1"

            HorizontalAlignment="Right"

            Width="100"

            Margin="2" />

    </Grid>

</Window>

Now, you'll notice right away that something's wrong when you see the blue squiggly line at the password binding:

Oh no! What are we going to do now? If we can't bind the password, and have to somehow retrieve it from the control, then we'll break the MVVM pattern, right? And we MVVM knights-in-shining-armour can't afford to deviate from the path of light that is MVVM. You see, the Password property can't be bound specifically because it shouldn't, but let's say that we're like most other developers and we're so blinded by this MVVM dogma that we don't care about the security concerns and we want an MVVM-friendly solution.

Well, no problem! It turns out that there actually is an MVVM-friendly way to bind the password - see the PasswordBoxAssistant and PasswordHelper implementations. To get up and running, let's add a new PasswordBoxHelper class to our project, and add the implementation from the second link:

    public static class PasswordHelper

    {

        public static readonly DependencyProperty PasswordProperty =

            DependencyProperty.RegisterAttached("Password",

            typeof(string), typeof(PasswordHelper),

            new FrameworkPropertyMetadata(string.Empty, OnPasswordPropertyChanged));

        public static readonly DependencyProperty AttachProperty =

            DependencyProperty.RegisterAttached("Attach",

            typeof(bool), typeof(PasswordHelper), new PropertyMetadata(false, Attach));

        private static readonly DependencyProperty IsUpdatingProperty =

            DependencyProperty.RegisterAttached("IsUpdating", typeof(bool),

            typeof(PasswordHelper));

        public static void SetAttach(DependencyObject dp, bool value)

        {

            dp.SetValue(AttachProperty, value);

        }

        public static bool GetAttach(DependencyObject dp)

        {

            return (bool)dp.GetValue(AttachProperty);

        }

        public static string GetPassword(DependencyObject dp)

        {

            return (string)dp.GetValue(PasswordProperty);

        }

        public static void SetPassword(DependencyObject dp, string value)

        {

            dp.SetValue(PasswordProperty, value);

        }

        private static bool GetIsUpdating(DependencyObject dp)

        {

            return (bool)dp.GetValue(IsUpdatingProperty);

        }

        private static void SetIsUpdating(DependencyObject dp, bool value)

        {

            dp.SetValue(IsUpdatingProperty, value);

        }

        private static void OnPasswordPropertyChanged(DependencyObject sender,

            DependencyPropertyChangedEventArgs e)

        {

            PasswordBox passwordBox = sender as PasswordBox;

            passwordBox.PasswordChanged -= PasswordChanged;

            if (!(bool)GetIsUpdating(passwordBox))

            {

                passwordBox.Password = (string)e.NewValue;

            }

            passwordBox.PasswordChanged += PasswordChanged;

        }

        private static void Attach(DependencyObject sender,

            DependencyPropertyChangedEventArgs e)

        {

            PasswordBox passwordBox = sender as PasswordBox;

            if (passwordBox == null)

                return;

            if ((bool)e.OldValue)

            {

                passwordBox.PasswordChanged -= PasswordChanged;

            }

            if ((bool)e.NewValue)

            {

                passwordBox.PasswordChanged += PasswordChanged;

            }

        }

        private static void PasswordChanged(object sender, RoutedEventArgs e)

        {

            PasswordBox passwordBox = sender as PasswordBox;

            SetIsUpdating(passwordBox, true);

            SetPassword(passwordBox, passwordBox.Password);

            SetIsUpdating(passwordBox, false);

        }

    }

You will also need to add the following usings at the top:

using System.Windows;

using System.Windows.Controls;

Now, let's fix our Password binding. First, add the following attribute to the Window declaration in the XAML so that we can access our project's classes (adjust namespace as needed):

        xmlns:local="clr-namespace:CsWpfMvvmPasswordBox"

Then update the PasswordBox declaration to use the PasswordBoxHelper as follows:

        <PasswordBox local:PasswordHelper.Attach="True"

            local:PasswordHelper.Password="{Binding Path=Password}"

            Grid.Row="1"

            Grid.Column="1"

            Margin="2" />

That did it! The project now compiles.

Now, let's see why what we have done is a very stupid thing to do. To do this, we're going to need this WPF utility called Snoop, so go over to their website, download it, and install it using the .msi file.

Run Snoop. All you'll see is a thin bar with a few buttons. On the right hand side, there is a button that looks like a circle (in fact it's supposed to be crosshairs). If you hover over it, it will explain how to use it:

Run the WPF application we just developed. Enter something into the PasswordBox, but shhhh! Don't tell anyone what you wrote there! :)

Next, drag those crosshairs from Snoop onto the WPF window:

When you let go, a window opens. In the treeview to the left, you can navigate through the mounds of crap that internally make up our simple application. When you find the PasswordBox, you'll also find the PasswordHelper:

...and as you can see, the PasswordHelper keeps the password exposed in memory so anyone who knows what he's doing can gain access to it. With a program like Snoop, anyone can access passwords that are bound.

There are a couple of lessons to take from this.

First, don't ever bind passwords in WPF. There are other alternatives you can use, such as passing your entire PasswordBox control as a binding parameter - although this sounds extremely stupid, it's a lot more secure than binding passwords. And arguably, it doesn't break the MVVM pattern.

Secondly, don't be so religious about so-called best practices such as MVVM. Ultimately they are guidelines, and there are many cases such as this where there are more important things to consider (in this case, security). For something as simple as a login window, it's much more practical to just do without MVVM and do everything in the codebehind. It isn't going to affect the scalability, maintainability, robustness [insert architectural buzz-word here], etc of your application if you make an exception that is rational.

Before ending this article, I would like to thank the person who posted this answer to one of my questions on Stack Overflow. That answer helped me understand the dangers of binding passwords, and provided the inspiration for this article. As further reading, you might also want to read this other question (and its answer) which deals with the security of processing passwords in memory in general (not just data binding).

That's all for today. Happy coding! :)

C# Security: Computing File Hashes

Hello again! :)

We're celebrating! :D Today, Programmer's Ranch turned one year old, and although I've turned most of my attention to an interesting spare-time project for the time being, I wanted to mark this occasion with a new article. And some cake.

Right, and today's article is about hashing. We've seen in "C# Security: Securing Passwords by Salting and Hashing" that a hash function transforms an input string into a totally different piece of data (a hash):

If you make even a slight change to the input, such as changing the first character from uppercase to lowercase, you get a totally different output:

Also, if you use a decent hash function (i.e. not MD5), it is normally not possible to get the input string from the hash.

In today's article, we're going to use hashes for something much simpler than securing passwords. We're going to hash the content of files, and then use that hash to check whether the file changed. Since I haven't been very impressed with SharpDevelop 5 Beta, I'm going to ditch it and use Visual Studio 2013 instead. You can use whatever you like - SharpDevelop, Visual Studio Express for Desktop, or maybe even MonoDevelop.

Create a new Console Application, and add the following at the top:

using System.Security.Cryptography;

This will allow you to use a variety of hash functions, which all derive from the HashAlgorithm class.

We'll also need a little helper function to convert our hashes from a byte array to a string, so that they may be displayed in hex in the command line. We'll use the following, which is a modified version of the Hash() method from "C# Security: Securing Passwords by Salting and Hashing":

        public static string ToHexString(byte[] bytes)

        {

            StringBuilder sb = new StringBuilder();

            foreach (byte b in bytes)

            sb.Append(b.ToString("x2").ToLower());

            return sb.ToString();

        }

Now, let's create a text file in the same folder as our .sln file and name it "test.txt", and put the following lyrics from the Eagles' "Hotel California" in it:

So I called up the Captain,

"Please bring me my wine"

He said, "We haven't had that spirit here since nineteen sixty nine"

And still those voices are calling from far away,

Wake you up in the middle of the night

Just to hear them say...

Let's read that file into memory. First, we need to add the following:

using System.IO;

We can now read the contents of the file into a string:

            string fileContents = File.ReadAllText(@"../../../test.txt");

...and quite easily compute the hash of those contents:

            using (HashAlgorithm hashAlgorithm = SHA256.Create())

            {

                byte[] plainText = Encoding.UTF8.GetBytes(fileContents);

                byte[] hash = hashAlgorithm.ComputeHash(plainText);

                Console.WriteLine(ToHexString(hash));

            }

            Console.ReadLine();

Note that I'm using SHA256 as the hash function this time - it's a lot more robust than MD5. If you check the documentation for the HashAlgorithm class, you can find a bunch of different hash algorithms you can use. As it is, we get the following output:

Now, let's see what happens if your little toddler manages to climb onto your keyboard and modify the file. Let's remove the first character in the file (the initial "S") - that might be within a toddler's ability - and save the file. When we rerun the program, the output is quite different:

And here we have already seen how hashing gives us a mean to verify a file's integrity, or in other words, check whether it has been tampered with. In fact, popular Linux distributions such as Ubuntu distribute MD5 hashes for the files they release, so that the people who can download them can check that they are really downloading the file they wanted, and not some weird video of goats yelling like humans:

So let's actually see this in action. After downloading an Ubuntu distribution, let's change the filename to that of the Ubuntu file we downloaded, and the hash algorithm to MD5:

            string fileContents = File.ReadAllText(@"../../../../ubuntu-14.04-desktop-amd64.iso");

            using (HashAlgorithm hashAlgorithm = MD5.Create())

Now, let's try to compute a hash of the Ubuntu file:

Oops! We tried to read a ~1GB file into memory, and that's a pretty stupid thing to do. Unless you've got a pretty awesome computer, you'll see the memory usage spike until you get an OutOfMemoryException, as above. And even if you do have a pretty awesome computer, you shouldn't load an entire massive file just to perform an operation on its contents.

In one of my first articles here, "C#: Working with Streams", I explained how you could read a file bit by bit (e.g. line by line) and work on those parts without having to have the entire file in memory at any one time. And quite conveniently, the hash algorithms have a variant of the ComputeHash() method that takes a stream as a parameter.

So let's change our code as follows:

        static void Main(string[] args)

        {

            using (FileStream fs = File.OpenRead(@"../../../../ubuntu-14.04-desktop-amd64.iso"))

            using (HashAlgorithm hashAlgorithm = MD5.Create())

            {

                byte[] hash = hashAlgorithm.ComputeHash(fs);

                Console.WriteLine(ToHexString(hash));

            }

Console.ReadLine();

        }

And let's run it:

There are a few things to note from the output:

• It computes pretty quickly, despite the fact that it's going through a ~1GB file.
• Memory levels remain at a pretty decent level (in fact the memory used by the program is negligible).
• The output matches the first hash in the list of hashes on the Ubuntu webpage (in the background of the above screenshot).

Wonderful! :) In this first anniversary article, we revisited the concept of hashing, and learned the following:

• There are several different hash algorithms provided by .NET that you can use, including MD5, SHA256, and others.
• A hash gives you a way to verify whether a file has been tampered with.
• Streaming provides the ability to process large files quickly and with very little memory overhead.

Thank you so much for reading, and please check back for more interesting articles here at Programmer's Ranch! :)