Erasing passwords from ram?

[Cym13]

On Monday, 6 May 2019 at 09:34:22 UTC, Dukc wrote:
> Oops, I forgot to check back this theard. But yes, just the 
> info I was looking for.
>
> On Wednesday, 1 May 2019 at 22:14:52 UTC, Cym13 wrote:
>>
>> There are very few relevant threat models where removing a 
>> password from RAM is an adequate solution.
>
> Not an adequate solution... What else is usually needed? You 
> can't mean hashing, because by definition one would not want to 
> delete the password in the first place, if there weren't hashes 
> made of it.
>
>> I'd rather focus on mitigating that threat by keeping 
>> boundchecking on, writing @safe code etc.
>
> I do. I was just curious if doing this trick brings any 
> practical extra safety. (By what I understood from your reply, 
> yes with operating systems or password managers but not 
> generally with servers, unless trying to guard it from it's 
> maintainers)
>
> And I'm also going to try to follow Walter's safety tip number 
> 1: never assuming the server won't crash. I'm going to make an 
> automatic restarter process for it.

The thing is, the most important concept in security is the 
threat model: what are you protecting against? There is no 
security without a threat model, protecting your data without 
first knowing from what makes absolutely no sense, so that 
question is paramount. Then we compare the cost of a successful 
attack and the benefit one gets from that attack: if the attacker 
can make a profit it's not secure. If the defense cost is greatly 
superior to the value of your asset it's not well spent and those 
resources should most likely be spent protecting against 
something else.

 From what I understand your threat model is that of a remote 
attacker finding a vulnerability leaking memory in a heartbleed 
fashion then finding credentials in that leaked memory providing 
access to sensitive resources. That's a rather constrained 
scenario which is good, but it's also a very rare scenario. Very 
few memory issues lead to memory leakage, especially while 
providing a way to control what is leaked. Memory corruption 
vulnerabilities (I include out-of-bound reading) generally either 
result in a crash or can be exploited for code execution.

If an attacker has code execution on your server the impact is 
bigger than that of memory disclosure and erasing credentials 
from memory doesn't mitigate that. But those bugs are way more 
common than controlled memory disclosure. However the solutions 
to memory corruptions are the same whether you're trying to 
protect against code execution or memory disclosure.

So what I'm trying to say is that, given your threat model, it 
does not seem relevant to protect against memory disclosure 
specifically: you want to protect against the larger and more 
common threat of memory corruptions and that happens to cover 
your current threat model. Unless what you want to protect is 
very very sensitive erasing passwords from memory would most 
likely be wasted time. But that's something that only you can 
assess.