Additional evidence of inadequate .NET implementation:
There is a ton of code & pointless complexity to minimize the time sensitive data has to remain in plaintext in memory, and zeroing buffers asap. Clearly, the "process memory compromise" threat vector is taken very seriously by the authors.
Does anyone see what the problem is? Hint: disposing "ms" in addition to closing will not fix the problem.
There are ~ 59 instances of this mistake in the codebase. The author(s) seem to come from c/c++ background, and make all kinds of assumptions about how .NET works - except that .NET doesn't work the way they think it works.
There is a ton of code & pointless complexity to minimize the time sensitive data has to remain in plaintext in memory, and zeroing buffers asap. Clearly, the "process memory compromise" threat vector is taken very seriously by the authors.
Here's a KeePass function that generates a key: https://github.com/wrouesnel/keepass/blob/master/KeePassLib/...
Does anyone see what the problem is? Hint: disposing "ms" in addition to closing will not fix the problem.
There are ~ 59 instances of this mistake in the codebase. The author(s) seem to come from c/c++ background, and make all kinds of assumptions about how .NET works - except that .NET doesn't work the way they think it works.
The generation of the Master Key: https://github.com/wrouesnel/keepass/blob/master/KeePassLib/...
Note that "pbNewKey" can be sitting in memory forever.
TL/DR: KeePass memory protection is completely ineffective (I only speak for .NET implementation).