Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

KeePassXC still lacks in-memory protection, so I stay with KeePass, with all its .NET troubles.


(Full disclosure: I contribute to KeePassXC)

In fact, KeePassXC has shown to have better memory protection than KeePass: https://keepassxc.org/blog/2019-02-21-memory-security/ (note the article is from February, some things have changed since then, see below). The only thing we do not have at the moment is in-memory encryption. We do, however implement the following security measures on all platforms:

- prevent swapping of master key hashes (using gcry_malloc_secure)

- prevent non-root / admin access to our process memory (KeePass does NOT have this)

- overwrite all dynamically allocated memory with zeros on free

- disable any kind of coredump or crash reporting

A patch for in-memory encryption is being worked on, but needs further testing before it can be merged: https://github.com/keepassxreboot/keepassxc/pull/3055

Please note that this still cannot fully prevent swapping out of secrets. As soon as things are to be displayed somewhere in the GUI, they are basically out of our hands. We also cannot fully protect everything while the database is being loaded or written. However, the same applies to KeePass. There is just too much going on with memory management on modern operating systems.


Thank you. You convinced me to try KeePassXC again.


I thought that it did now. For example this PR: https://github.com/keepassxreboot/keepassxc/pull/3020

Edit: Also, see this PR: https://github.com/keepassxreboot/keepassxc/pull/371


https://github.com/keepassxreboot/keepassxc/issues/2718#issu...

I'd guess it's this one:

> KeePassXC also cannot prevent data extraction from a hibernation file which stores your computer's memory to disk when going to sleep.

KeePass uses DPAPI so password-storage memory is not written to swap (and I guess hibernatefile) in cleartext. Note that this doesn't protect against reading the memory directly[0].

Though (on unices) it doesn't mention mlock(2) either.

[0] https://www.securityevaluators.com/casestudies/password-mana... subsection "Exposure of Cleartext Entries in Memory" of the Keepass section


Thanks for pointing out. Nice to see progress in this direction.


Can elaborate more on the practical benefits of encrypted memory? Presumably this is mainly good for multi-user systems? On the average single-user system it seems that if you can already read memory there are 1000 other possible exploits that are cheaper / easier to perform (ie. keylog, screen capture, etc).


AFAIK the only thing it protects you from is generic malware that scans process memory for passwords. It’s trivial to bypass though: all you need to do is patch the code as it’s running to dump all the plaintext entries for you.

> there are 1000 other possible exploits that are cheaper / easier to perform (ie. keylog, screen capture, etc).

Keepass has mitigations for those as well.


> AFAIK the only thing it protects you from is generic malware that scans process memory for passwords.

Apparently it doesn't even do that: https://www.securityevaluators.com/casestudies/password-mana... (section Keepass)

Possibly because keepass uses the wrong flag? https://docs.microsoft.com/en-us/dotnet/api/system.security.... seems to say that the memory segment can be decrypted by either:

* all processes running on the box

* all processes owned by the same user

* only this process

Alternatively, might be because C# and the memory protection primitives don't prevent the GC from copying its data out of the protected area? IDK

edit: ah, or they might be using ProtectedData rather than ProtectedMemory, that only has the "same machine" and "same user" levels of protection: https://docs.microsoft.com/en-us/dotnet/api/system.security....


Crash reports often include memory dumps. Firefox automatically reports these to Mozilla - there's plenty of other software that auto-reports crash data as well. If that crash data includes in-memory credentials, that could lead to your master password being compromised.



> Crash reports often include memory dumps. Firefox automatically reports these to Mozilla

Of the process in question, not the entire system. A Firefox crash dump can potentially still include credentials and private keys, of course.


What troubles? I recently started to use it, and so far I did not encounter any troubles. For me the killer feature of KeePass is that it allows me to safely use it without typing master password using -pw-enc command line argument. I hated to type my password every day over and over again with 1Password. Especially because I understand that it's very weak protection if someone already break in my computer.


I reckon OP dislikes the need to have the whole Mono runtime to run one small-ish application. At least that's the reason I always preferred the native ports.


Ah, I'm Windows user, I didn't even know that you could run KeePass on non-Windows systems.


> without typing master password using -pw-enc command line argument

Process command lines are world-readable on various operating systems, so passing passwords over them is generally not a good idea.


It's not a clear text password. It's encrypted with Windows user credentials. If someone just steals it, it won't be useful by itself.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: