Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

How secure is the WPF PasswordBox, really?

I've already asked a couple of questions around the PasswordBox recently, but at the heart of my issue, I need an extremely secure way of getting very sensitive information inputted into my .Net application.

Out of the box, the WPF PasswordBox is the go to control for getting passwords, or other sensitive information. For the sake of security, it provides a SecureString object through the SecurePassword property which is, in my case, secure enough for my needs. However, there is one major flaw that I see with this control-- it has a Password property which is the user-entered content in an insecure .Net string.

I would like to assume that if I never access the Password property within my application, an insecure version of my sensitive information will never be generated and have to be garbage collected. That fine. However, since the point of the secured form of the string is to keep the value secure from a snooping process (I assume) that can read the .Net memory, could the same snooping malicious codes simply look for a PasswordBox that is hanging around in memory and find some way to access the Password field, making the use of the SecureString value essentially useless?

I will admit, I have no clue how these exploits are executed. However, if the problem is that some application might be sniffing your variables in the .Net memory manager/garbage collector, it would seem plausible to me that all they'd have to do is access the PasswordBox control object, rather than a string object in memory and simply access the Password property. What might I be missing in this puzzle? How is the PasswordBox even secure if it contains a Password property in clear text?

like image 904
RLH Avatar asked Nov 30 '17 15:11

RLH


2 Answers

PasswordBox.Password property creates .NET string from SecurePassword property, it does not store it as string internally. The whole point of using SecureString is to reduce amount of time sensetive data is present in memory, and reduce number of copies of that sensetive data. You can read more about SecureString in documentation.

SecureString is encrypted (if possible, and usually it is), so if someone can just read raw memory (such as someone stealing your memory dump) - he will not be able to read your password from it. If your application is so compromised that attacker can inject his own dll into your process and run arbitrary code there - then you have bigger problems anyway (and still there is high chance that password will not be present in memory already).

That said, you can still follow some reasonable guidelines when using PasswordBox and SecureStrings in general.

  1. Always dispose result of PasswordBox.SecurePassword if you ever need to access it:

    using (var pwd = myBox.SecurePassword) {
        // do stuff
    }
    

This might look strange (disposing something returned by property), but it should be done, because this property returns a copy of SecureString and should have been a method instead, but for some reason is property.

  1. Access Password property as rare as possible, preferrably only once when you really need it. You don't want copies of password to stay in memory more and longer than needed.

  2. Always call yourBox.Clear() when you are done. This will set password to empty string and clear interal SecureString memory.

like image 90
Evk Avatar answered Oct 05 '22 11:10

Evk


You don't have to take guesses, you can just look it up.

The passwordbox has no field Password. It has a field PasswordTextContainer that keeps the password.

This means the documentation is correct that says

Remarks

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.

If you don't read it as plaintext and keep it as plaintext in your app, it won't be plaintext.

But again, don't trust random people on the internet (including me!), just look at it yourself.

like image 36
nvoigt Avatar answered Oct 05 '22 11:10

nvoigt