How to bind to a PasswordBox in MVVM

K

32

298

I have come across a problem with binding to a PasswordBox. It seems it's a security risk but I am using the MVVM pattern so I wish to bypass this. I found some interesting code here (has anyone used this or something similar?)

http://www.wpftutorial.net/PasswordBox.html

It technically looks great, but I am unsure of how to retrieve the password.

I basically have properties in my LoginViewModel for Username and Password. Username is fine and is working as it's a TextBox.

I used the code above as stated and entered this

<PasswordBox ff:PasswordHelper.Attach="True"
    ff:PasswordHelper.Password="{Binding Path=Password}" Width="130"/>

When I had the PasswordBox as a TextBox and Binding Path=Password then the property in my LoginViewModel was updated.

My code is very simple, basically I have a Command for my Button. When I press it CanLogin is called and if it returns true it calls Login.
You can see I check my property for Username here which works great.

In Login I send along to my service a Username and Password, Username contains data from my View but Password is Null|Empty

private DelegateCommand loginCommand;

public string Username { get; set; }
public string Password { get; set; }


public ICommand LoginCommand
{
    get
    {
        if (loginCommand == null)
        {
            loginCommand = new DelegateCommand(
                Login, CanLogin );
        }
        return loginCommand;
    }
}

private bool CanLogin()
{
    return !string.IsNullOrEmpty(Username);
}

private void Login()
{
    bool result = securityService.IsValidLogin(Username, Password);

    if (result) { }
    else { }
}

This is what I am doing

<TextBox Text="{Binding Path=Username, UpdateSourceTrigger=PropertyChanged}"
         MinWidth="180" />

<PasswordBox ff:PasswordHelper.Attach="True" 
             ff:PasswordHelper.Password="{Binding Path=Password}" Width="130"/>

I have my TextBox, this is no problem, but in my ViewModel the Password is empty.

Am I doing something wrong or missing a step?

I put a breakpoint and sure enough the code enter the static helper class but it never updates my Password in my ViewModel.

Konrad answered 27/9, 2009 at 16:34 Comment(2)

Well it turns out the code didn't work but i tried an alternative code here and it works perfectly. blog.functionalfun.net/2008/06/… – Konrad 27/9, 2009 at 18:1

Doesn't passing in the whole passwordbox control go against separating the view from the viewmodel? – Escarole 14/4, 2010 at 20:29

S

186

Sorry, but you're doing it wrong.

People should have the following security guideline tattooed on the inside of their eyelids:
Never keep plain text passwords in memory.

The reason the WPF/Silverlight PasswordBox doesn't expose a DP for the Password property is security related.
If WPF/Silverlight were to keep a DP for Password it would require the framework to keep the password itself unencrypted in memory. Which is considered quite a troublesome security attack vector. The PasswordBox uses encrypted memory (of sorts) and the only way to access the password is through the CLR property.

I would suggest that when accessing the PasswordBox.Password CLR property you'd refrain from placing it in any variable or as a value for any property.
Keeping your password in plain text on the client machine RAM is a security no-no.
So get rid of that public string Password { get; set; } you've got up there.

When accessing PasswordBox.Password, just get it out and ship it to the server ASAP. Don't keep the value of the password around and don't treat it as you would any other client machine text. Don't keep clear text passwords in memory.

I know this breaks the MVVM pattern, but you shouldn't ever bind to PasswordBox.Password Attached DP, store your password in the ViewModel or any other similar shenanigans.

If you're looking for an over-architected solution, here's one:
1. Create the IHavePassword interface with one method that returns the password clear text.
2. Have your UserControl implement a IHavePassword interface.
3. Register the UserControl instance with your IoC as implementing the IHavePassword interface.
4. When a server request requiring your password is taking place, call your IoC for the IHavePassword implementation and only than get the much coveted password.

Just my take on it.

-- Justin

Strohbehn answered 29/9, 2009 at 15:31 Comment(17)

Couldn't you use the SecureString in the VM for WPF to solve this problem? It doesn't seem like there is something for Silverlight. – Korella 9/10, 2009 at 21:29

I agree with your intention and the message you are conveying but your answer implies that the password string is never in memory if you follow this approach. The value of the password will be in memory from the moment the user types it. Eliminating the property holding your passphrase is a good idea and will limit the copies of your password that get left laying around for the garbage collector to reap or that could perhaps be found by other managed and unmanaged code running as part of your program, but will not hide it altogether. – Dermatology 18/8, 2010 at 11:57

For most cases, you don't need that level of security. What's the point of making that one thing hard when there're so many other ways to steal passwords? Atleast WPF should've allowed the use of SecureString like @Korella said. – Telepathy 7/2, 2011 at 21:33

Out of curiosity, is there still no way to bind to the SecureString version? It is completely understandable that you might not want to provide a binding to Password directly, but to have no binding at all just makes the entire control more difficult / irritating to use. Clearly there are workarounds for this, but there shouldn't have to be. – Sinhalese 19/9, 2011 at 18:13

If the bad guys have access to the RAM of your machine, you have bigger issues than them stealing your password. – Katowice 17/1, 2012 at 9:20

I think the problem that @JusinAngel is pointing out when you see how easy it is to access internal properties using external tools like snoop, which could just be running in the background recording the text property on anything called password. It wouldn't be that difficult of an attack. – Quintic 3/4, 2012 at 1:55

I agree, getting the value of the PasswordBox.Password property using tools like Snoop is so easy (much easier than retieving it from the ViewModel) that it is not worth hiding that string in the ViewModel. – Belew 29/6, 2012 at 12:34

Sometimes we just need a simple PasswordBox control just to hide chars! no meaning of a password in a form login.. – Vulgus 10/12, 2012 at 10:33

For years, I have been using a custom user control that behaves just like PasswordBox, but only returns the text value as SecureString. Yes, this prevents Snoop from displaying the password in plain text. However, the plain text value of SecureString can still be extracted quite easily and only deters novice hacks. If your system is at risk of covertly employing key loggers and sniffers like Snoop, your should re-evaluate at your system security. – Consign 7/5, 2013 at 0:14

The name PasswordBox or the property Password doesn't necessarily imply that concerns in all cases, or in the typical assumed case, match the concerns of the implementation. It's a reasonable guess that this person was "doing it wrong" in this case. But there are cases where the only concern is direct visibility, and pre-populated, but password-style hidden text is desired, despite NO needs for underlying data security. This exists among conceivable reasons for wanting to use/abuse a PasswordBox-like control. – Falsetto 29/5, 2015 at 14:17

It's inexplicable that there isn't a bindable SecureString property for the password. It would introduce no extra security concerns over a CLR property. Furthermore, SecureString is really only useful in very limited circumstances. Mostly it just gives the illusion of security. My advice - subclass TextBox and make your own password box. It's quite easy and you don't have to go through all these ridiculous hoops. – Dvinsk 11/7, 2017 at 1:56

@Strohbehn Could you give us an idea of what could happen if I keep a plain text password in memory? I'm curious as to what exactly would be the security threat – – Darrondarrow 23/5, 2018 at 20:39

@RaikolAmaro, Clear password in memory can be snooped. This link will give some explanations. security.stackexchange.com/questions/29019/… – Pentlandite 22/8, 2018 at 14:43

@Pentlandite Thanks a lot. That is exactly what I was looking for. – Darrondarrow 22/8, 2018 at 18:37

Why not using postcards to send passwords? It is completely safe from memory hacking. – Fleenor 19/4, 2019 at 1:11

Hi guys !! If I can help you, do you should try the simple approach, don't use viewmodel for this case, but use the code-behind, so there you can get all values using a simple code, var user = this.txtUser.Text; this.txtPassWord.Password(). The shorter the better !!!! – Moult 26/12, 2020 at 23:44

I don't want to just send the password to the server. I want to encrypt it and send that to the server. – Stocker 12/8, 2021 at 14:59

V

245

Maybe I am missing something, but it seems like most of these solutions overcomplicate things and do away with secure practices.

This method does not violate the MVVM pattern and maintains complete security. Yes, technically it is code behind, but it is nothing more than a "special case" binding. The ViewModel still has no knowledge of the View implementation, which in my mind it does if you are trying to pass the PasswordBox in to the ViewModel.

Code Behind != Automatic MVVM violation. It all depends on what you do with it. In this case, we are just manually coding a binding, so its all considered part of the UI implementation and therefore is ok.

In the ViewModel, just a simple property. I made it "write only" since there shouldn't be a need to retrieve it from outside the ViewModel for any reason, but it doesn't have to be. Note that it is a SecureString, not just a string.

public SecureString SecurePassword { private get; set; }

In the xaml, you set up a PasswordChanged event handler.

<PasswordBox PasswordChanged="PasswordBox_PasswordChanged"/>

In the code behind:

private void PasswordBox_PasswordChanged(object sender, RoutedEventArgs e)
{
    if (this.DataContext != null)
    { ((dynamic)this.DataContext).SecurePassword = ((PasswordBox)sender).SecurePassword; }
}

With this method, your password remains in a SecureString at all times and therefore provides maximum security. If you really don't care about security or you need the clear text password for a downstream method that requires it (note: most .NET methods that require a password also support a SecureString option, so you may not really need a clear text password even if you think you do), you can just use the Password property instead. Like this:

(ViewModel property)

public string Password { private get; set; }

(Code behind)

private void PasswordBox_PasswordChanged(object sender, RoutedEventArgs e)
{
    if (this.DataContext != null)
    { ((dynamic)this.DataContext).Password = ((PasswordBox)sender).Password; }
}

If you wanted to keep things strongly typed, you could substitute the (dynamic) cast with the interface of your ViewModel. But really, "normal" data bindings aren't strongly typed either, so its not that big a deal.

private void PasswordBox_PasswordChanged(object sender, RoutedEventArgs e)
{
    if (this.DataContext != null)
    { ((IMyViewModel)this.DataContext).Password = ((PasswordBox)sender).Password; }
}

So best of all worlds - your password is secure, your ViewModel just has a property like any other property, and your View is self contained with no external references required.

Vevina answered 28/7, 2014 at 17:45 Comment(14)

This one looks good to me! If you wanted to be super strict on the security side im not sure this would cut it, but to me its a perfect middle ground. thanks! – Peers 29/7, 2014 at 17:20

Thanks for practicality over rigid dogma about MVVM and paranoia. Works great, thanks. – Ewell 17/12, 2014 at 17:7

The SecureString example would be great with this extension blogs.msdn.com/b/fpintos/archive/2009/06/12/… – Tuition 18/3, 2015 at 13:8

Nice! Btw, Microsoft documentation has an "important note" stating that it should be disposed: msdn.microsoft.com/en-us/library/… – Centenarian 9/9, 2015 at 13:46

Nice indeed. I wish MS would have just added a Password DP of type SecureString to this control. – Displace 1/10, 2015 at 17:12

See my answer for a variant that uses a behavior instead of code behind and allows you to reset the password from the viewmodel. – Erg 12/1, 2016 at 13:33

This is the perfect answer, as it keeps security and MVVM. – Makebelieve 24/4, 2016 at 3:34

This is the best answer. Why is it so far down the page (11th answer for me)? – Genic 18/1, 2017 at 2:32

I'm trying to follow this example but the type of my PasswordBox.Password is string, not SecureString, and it won't let me cast one to the other (and I am not sure I should be doing that anyway). Anyone got any ideas what may be wrong? Found it! The property I want is SecurePassword. Maybe something changed in the framework since this example. – Shope 26/6, 2017 at 12:21

If you look at the first example, it uses SecurePassword. The second one using Password includes the disclaimer "If you really don't care about security or you need the clear text password..." So nothing has changed, both were shown in the original post. – Vevina 28/6, 2017 at 0:46

the datacontext is always null, any idea? – Izettaizhevsk 29/6, 2017 at 9:6

You have to actually have set the DataContext, but that's part of data binding. You should be doing it as part of your view setup. If you aren't setting a DataContext, you won't be able to bind anything, password or otherwise. – Vevina 6/7, 2017 at 12:58

Interesting side-note. I tried making the get-er for SecurePassword public, and Windows Defender reported a Trojan pattern named Fuery.B!cl on my system every time I ran the program. – Ardatharde 22/7, 2017 at 19:49

This is great and pragmatic answer for most common use cases. – Claro 30/7, 2019 at 10:23

G

221

My 2 cents:

I developed once a typical login dialog (user and password boxes, plus "Ok" button) using WPF and MVVM. I solved the password binding issue by simply passing the PasswordBox control itself as a parameter to the command attached to the "Ok" button. So in the view I had:

<PasswordBox Name="txtPassword" VerticalAlignment="Top" Width="120" />
<Button Content="Ok" Command="{Binding Path=OkCommand}"
   CommandParameter="{Binding ElementName=txtPassword}"/>

And in the ViewModel, the Execute method of the attached command was as follows:

void Execute(object parameter)
{
    var passwordBox = parameter as PasswordBox;
    var password = passwordBox.Password;
    //Now go ahead and check the user name and password
}

This slightly violates the MVVM pattern since now the ViewModel knows something about how the View is implemented, but in that particular project I could afford it. Hope it is useful for someone as well.

Goer answered 10/1, 2011 at 17:57 Comment(8)

Hello Konamiman,when the Execute method is called.In my viewmodel i have a class User(login,pass) and a command authenticate.How can i use Execute in that context? – Showoff 2/5, 2012 at 5:40

very helpful, thanks. fyi, someone might be used to seeing something like _loginCommand = new RelayCommand(param => Login(UserName, (PasswordBox)param), param => CanLogIn); – Chapple 19/7, 2012 at 18:0

this is an ok solution but fails for something like a password + password confirmation combo – Seabrooke 28/4, 2014 at 12:34

Hello Konamiman, I'm using your solution but it doesn't work on Windows 8.1 Store app. I've asked this question: #26222094 – Longbow 6/10, 2014 at 19:17

Thanks for this! This solved a huge problem I had with moving the data from the UI thread to the main program thread. Make sure to implement the SecureString approach, and ~get rid of the password as soon as possible~. Dump it. Dispose it. Clear it. Do what you need to do. Also, make sure you implement IDisposable. – Sabella 5/2, 2015 at 22:3

You can also use x:Name="MyPasswordBox" – Lignify 3/2, 2016 at 15:24

This is the quick and easy solution I was looking for. Thanks! – Galatea 11/7, 2018 at 8:1

Handling controls in the view model clearly violates the MVVM pattern. There are far better solutions. – Canonicity 28/4, 2020 at 13:27