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.
