Erasing passwords from ram?

[Cym13]

On Tuesday, 30 April 2019 at 08:15:15 UTC, Dukc wrote:
> I am currently programming a server. So I got the idea that 
> after I've generated all the hashes I need from a password, I 
> want to erase it from RAM before discarding it, just to be sure 
> it won't float around if the server memory is exposed to 
> spyware by some buffer overflow. Is this wise caution, or just 
> being too paranoid?
>
> And if it is worthwhile, do I have to do this:
> ```
> foreach(ref part; cast(ubyte[]) rootPassword) 
> volatileStore(&part, 0);
> ```
>
> Or, can I rely on that the compiler won't optimize this out?
> ```
> rootPassword[] = '\0'
> ```
>
> `rootPassword` is allocated on the heap, but only locally 
> referred to.

There are very few relevant threat models where removing a 
password from RAM is an adequate solution, I'm not sure it's 
worth the trouble.

For comparison one case where it's considered important is 
removing the master password from a password manager from RAM to 
prevent another person finding the computer unlocked to recover 
it by memory inspection (which it would have the rigth to do 
since the process would be from the same user).
That's quite specific and a server isn't nearly as exposed.

That said, if you want to remove it, make sure to audit all 
functions that use it from the moment it enters memory to check 
that they don't make a copy for some reason (or use a type that 
doesn't allow copies). It's no use removing it at one place if 
it's still at another. In particular a pattern I see often is 
that you have a function that reads the password from a 
file/stdin/whatever onto the stack and sets on the heap the 
object you'll use throughout the program then returns. You will 
think of checking the use of that object, but may forget to clear 
the setter's buffer before returning leaving it in a stack's 
frame. You should also make sure that your compiler isn't 
recognizing that this part of memory isn't used later and 
optimizing away the overwrite call.

This is lots of work for a vulnerability that should not be there 
and may not lead to memory disclosure even if it is present. I'd 
rather focus on mitigating that threat by keeping boundchecking 
on, writing @safe code etc.