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.
