5

I recently asked the question "Is it a bad idea to bind PasswordBox password?" The gist was that although WPF applications nowadays tend to follow the MVVM design pattern, the WPF PasswordBox seems to be intentionally designed to keep passwords from being bound. And yet, people have found ways of binding them anyway, meaning that they are kept in memory as part of the viewmodel (even worse than if the password is simply retrieved from the PasswordBox and checked on the spot, I guess).

This situation leads to a more fundamental question. What are the real risks of storing a password in memory? What can happen and how likely is it to happen? (When I say store, it means as part of the login process; they would never be kept in memory afterwards... except in the sense that they'd reside in memory anyway until the garbage collector kicks in.)

Some think that "If an attacker can read your memory, you have 100% lost." (comment to this question), which indicates that whether you store passwords in memory or not might be superfluous, since you're screwed anyway if they have access to your memory (see Troy Hunt's article on Heartbleed, which shows an example of how access to memory in an umnanaged environment can be pretty disastrous).

On the other hand it's possible to keep passwords out of managed memory - this blog post shows a pretty detailed example, and this MSDN article shows the method of converting to and from SecureStrings. However I'm not totally convinced about how necessary this is. First, it takes a fair amount of work to do this, and following the "if they can read your memory, you're screwed anyway" argument, it might not even be useful. Secondly, just because the password is in unmanaged memory, it doesn't mean it's safe (see Heartbleed example above); the advantage is really in limiting the amount of time for which the password is in memory, and in zeroing that memory afterwards.

So... in summary, is it worth going to these lengths to keep passwords out of managed memory?

Community
  • 1
  • 1
Gigi
  • 28,163
  • 29
  • 106
  • 188
  • 2
    Before heartbleed you might have got a very different answer to *after* heartbleed... – Marc Gravell May 21 '14 at 08:47
  • Heartbleed has generated a lot of hype, to be sure. I'm interested in the security perspective, but heartbleed did give context to these kinds of risk for people like me who aren't security professionals. – Gigi May 21 '14 at 08:51
  • 1
    I believe that the argument 'If an attacker can read your memory, you have 100% lost.' is not that valid anymore after the heartbleed. If they can read your memory it might be the only thing they can do and they cannot do anything else and you might not be that screwed as it seemed. – honzajscz May 21 '14 at 08:52
  • @Honzajscz I'm not sure what you mean... the point here is that access to memory means that they can read sensitive data anyway, and possibly do even more destructive stuff with the code that's being executed (or at least that's the way I understand it). – Gigi May 21 '14 at 08:56
  • 1
    @Gigi What you stated is the meaning of the quote. But the heartbleed problem showed that if somebody can get data out of your memory it does not automatically mean that he can do also other stuff on your machine and therefore it is still worth it to secure sensitive data even in memory. Did I make it clearer? – honzajscz May 21 '14 at 13:11
  • Oh yes, very interesting point, now that I understand it. – Gigi May 21 '14 at 13:44

2 Answers2

4

You seem to be concerned about the user-side of security. I think we agree that if your attacker can write your process memory, your security is gone whatever clever tricks you may employ. If your attacker can neither read nor write your process memory, you are safe even in your scenario of passwords in memory.

So the question focuses on the scenario that your attacker can freely read your process memory, but cannot manipulate it. Whatever you save, encrypt or hide, your routine to load, decrypt or unveil is in memory, too. So basically, every method you can employ to secure your data is not hard security, it's security by obscurity. Sooner or later, it will be read, too. Then it will be used to break your security.

So as long as you don't have some really nice and freaky hardware, if someone is able to read your process, he's able to break your security. It may take a while, the better your security measures are, the longer it will take. But it's never "secure" by design, it's only secure if it takes more effort than it's worth to break that security.

As a personal opinion not backed by facts, I think that if someone got read-process privileges on your Windows application, you are gone security-wise. If he got read process privileges, he has rooted your box anyway.

nvoigt
  • 75,013
  • 26
  • 93
  • 142
  • The question is specifically about Passwords. Exposing sensitive information stored in one system is bad, but exposing Password is even worse. The user might use the same password or the 'same pattern' for other accounts. Therefore Password needs to be much more secure that any other 'sensitive' information. – MVarman May 21 '14 at 09:35
  • "if someone is able to read your process, he's able to break your security." does that mean that I shouldn't bother encrypting stuff since it'll be decrypted anyway? – Steffen Winkler May 21 '14 at 12:19
  • 1
    If you need 100% security, then yes, if the key, the ivector and the decrypt algorithm can be read, decrypting your secrets is theoretically trivial and therefor insecure. However, if you aren't guarding state secrets, "theoretically trivial" may practically be too much work for an attacker and he'll just not bother. It's just like a lock. Any idiot can force a lock but people don't bother because for most locked doors they are not interested in what is behind the door. – nvoigt May 21 '14 at 14:11
2

I don't agree with "If an attacker can read your memory, you have 100% lost".

This is the attitude that encourages people to go to the extent of storing clear text password in database. If you ask them, they would probably say, "If an attacker can read your database, you have 100% lost".

Compromising Password is much worse than exposing the system memory or database. Because password gives the attacker access to other systems the user is registered to, not just the system which is exposed. So go to any extreme to secure the password. There is no excuse for not implementing the security guidelines referenced in the question. If for any reason (lazy?) you cant implement them, at least hash the password as early as possible.

MVarman
  • 549
  • 2
  • 9
  • I understand your point, but it is much easier to compromise the database than the memory of a running process, so I'm not sure whether that is a valid argument. – Gigi May 21 '14 at 10:33
  • My point is, it is not easy, but is [possible](http://www.codeproject.com/Articles/670373/Csharp-Read-Write-another-Process-Memory) (think of virus or spywares). The vulnerability depends on the kind of environments where your application is used. Different systems need different level of security. All I am saying is, if you want to skip implementing any security recommendations, do it after understanding the risk. Not with the assumption that 'it is not required'. – MVarman May 21 '14 at 11:10
  • Please note that I did not mean to say that additional encryption is a bad thing or that passwords should not be hashed. To the contrary. I'm just saying that these measures only make the attacker spend more resources, it does not make it unbreakable. Read access is like getting hit by a truck. A helmet won't help. That does not mean I advocate wearing no helmet. Every little bit might be the tiny amount needed to get away unharmed. – nvoigt May 21 '14 at 14:36
  • 1
    @nvoigt I do agree, it is a bit overkill in some (if not most) situations. My only concern was the reason.. "If an attacker can read your memory, you have 100% lost.". This is not a valid because, managed string may remain in memory even after you close the application (until it is physically overwritten), or could be stored in memory dump or page files. Think of users who access your system from a shared/public computers. – MVarman May 21 '14 at 16:56