How risky is it to store passwords in memory? [closed]

Question

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?

Answer 1

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.