3

I just stumbled across the fact that the Password property of WPF PasswordBoxes is not bindable for security reasons, which makes using them quite cumbersome in a MVVM context. Answers like https://stackoverflow.com/a/1493330/3198247 suggest that otherwise, the password might be stored in plain text in memory at runtime, which would be a bad idea since it could potentially be read by malware.

However, I still don't seem to understand the reason in general or that answer. There, it says Keeping your password in plain text on the client machine RAM is a security no-no.. However, the password is in memory as soon as it is typed as I'm able to access it from code. So why would malware not be able to read it directly from the textbox? Am I missing another point here?

edit: To clarify, esp. w/ regards to Sheridan's answer: Assume a PasswordBox where a user types "pw" as his password. Then, clearly "pw" is in memory as I can retrieve it via PasswordBox.Password. Why is it then insecure to additionally be able to bind it to a string property of a ViewModel? Then, "pw" would at most be contained in two strings, but as far as I can see, this should not make it any more or less secure. Or is the point really to "remind" the programmer that the PW should not be stored for longer than needed?

Community
  • 1
  • 1
anderas
  • 5,744
  • 30
  • 49
  • Binding `PasswordBox.Password` to a string property isn't ideal (just like using it in the first place isn't ideal), but binding `PasswordBox.SecurePassword` to a `SecureString` shouldn't hurt security. – CodesInChaos Mar 20 '14 at 08:50
  • 2
    `SecureString` doesn't protect against malware at all, it only prevents passwords from appearing in the swap file and crash dumps. – CodesInChaos Mar 20 '14 at 08:54

2 Answers2

1

Have a read of this answer Why is char[] preferred over String for passwords? I know it is java but I believe the same rule apply. But depending on the level of security required for your system it should be enough. Theres always ways that malware will obtain information e.g. keylogging but theres only so much you can do.

Community
  • 1
  • 1
Chris
  • 915
  • 8
  • 28
  • I do believe there is a better way than using char[]. Have a look at https://msdn.microsoft.com/de-de/library/system.security.securestring(v=vs.110).aspx – Noel Widmer Feb 04 '16 at 21:49
-1

You are missing something.

Plain passwords should never be stored in a database. Instead, passwords are encrypted and then stored in the database. When a user tries to log in, they type their text which you should immediately encrypt and compare to the encrypted password from the database.

Therefore, we never see the unencrypted password, either in the database, or the code.

Sheridan
  • 68,826
  • 24
  • 143
  • 183
  • I wasn' talking about databases or the storage of passwords there. I was actually referring to the point where/before I get the password from the input box. Obviously, at that point, the password needs to be in memory since I cannot encrypt it it without having the plaintext. Is the point really only to a) be so annoying that it basically pushes the programmer to search for ugly workarounds (see the lots of binding helper classes for this case) or b) have the password in plaintext for as short as possible by making them actively retrieve it once they need it? – anderas Mar 19 '14 at 17:20
  • 1
    We're not talking about a database here - we're talking about RAM. – CodesInChaos Mar 20 '14 at 08:51
  • When you only need to use a password to verify user logins, you shouldn't encrypt the password in the database, you should hash it with a proper password hash (bcrypt, scrypt, PBKDF2). You can encrypt or pepper the hash, but that doesn't buy you much since an attacker who cans steal the db can most likely steal the key as well (unless you're using a HSM). – CodesInChaos Mar 20 '14 at 08:57
  • This doesn't really help in any way. The WPF PasswordBox control stores the password in plain text anyway, which isn't exactly the "correct" way Sheridan is explaining. And really, there is no way of not seeing the unencrypted/unhashed password at all in the code that I can think of, since the user must be able to enter it! – almulo Jun 04 '15 at 12:48