title: How risky is it to store passwords in memory?
body: <p>I recently asked the question "<a href="https://stackoverflow.com/questions/23031549/is-it-a-bad-idea-to-bind-passwordbox-password">Is it a bad idea to bind PasswordBox password?</a>" 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).</p>
  
  <p>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 <em>store</em>, 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.)</p>
  
  <p>Some think that "<em>If an attacker can read your memory, you have 100% lost.</em>" (comment to <a href="https://stackoverflow.com/questions/14293344/hashing-a-securestring-in-net">this question</a>), 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 <a href="http://www.troyhunt.com/2014/04/everything-you-need-to-know-about.html" rel="nofollow noreferrer">Troy Hunt's article on Heartbleed</a>, which shows an example of how access to memory in an umnanaged environment can be pretty disastrous).</p>
  
  <p>On the other hand it's possible to keep passwords out of managed memory - <a href="http://danielhilliards-dotnetlearningblog.blogspot.com/2011/08/protecting-passwords-from-forensic.html" rel="nofollow noreferrer">this blog post</a> shows a pretty detailed example, and <a href="http://blogs.msdn.com/b/fpintos/archive/2009/06/12/how-to-properly-convert-securestring-to-string.aspx" rel="nofollow noreferrer">this MSDN article</a> 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.</p>
  
  <p>So... in summary, is it worth going to these lengths to keep passwords out of managed memory?</p>