If the memory in which the master key resides is not locked, then it may be written to the page file. An attacker may thus boot the machine from an external disk, mount the disk, read the page file, obtain the master key from the page file, and then decrypt the password database. The attack requires physical access but also works with a cloned disk, so the user need not even realize it has happened.
It's a standard attack. It's also not far-fetched to assume that an attacker could create memory pressure, for example by running a trojan process as an ordinary that uses as much available memory as possible, in order to ensure the master key is paged to disk. Whether you want to safeguard against this scenario or not is another question, it always depends on the threat model. I don't know how good this memguard is, but if it does what it promises, then it would likely make the application more secure. On Monday, October 15, 2018 at 9:18:18 PM UTC, robert engels wrote: > > As long as the passwords are not stored in plain text in memory - meaning > they are only temporarily decoded in order to be provided (and then the > memory wiped) - there is no difference than the underlying security of the > file encryption on disk, no ? > > > On Oct 15, 2018, at 4:13 PM, Christopher Nielsen <m4dh...@gmail.com > <javascript:>> wrote: > > > > On Mon, Oct 15, 2018 at 1:28 PM Matthias Schmidt > > <matthias...@gmail.com <javascript:>> wrote: > >> > >> Hi Eric, > >> > >> thanks *a lot* for your valuable feedback! I really appreciate it. See > comments inline: > >> > >> Am Montag, 15. Oktober 2018 12:09:32 UTC+2 schrieb EricR: > >>> > >>> Since you're looking for opinions on the security concept, two > questions spring immediately to my mind: > >>> > >>> 1. Does the daemon keep the sensitive data in locked memory that > cannot be paged out? If so, how cross-platform is this? > >> > >> > >> No it doesn't. As of now i consider the root-user a good guy ;-) > >> He's the only one who could access the pagefiles anyway. > >> > >> So is this really an issue? If yes i could use this cross-platform > solution to pin the key: > >> > >> https://github.com/awnumar/memguard > >> > >> > >>> > >>> > >>> 2. How does the client communicate securely with the daemon? Which > encryption protocol/handshake is used for this? (If it just uses a socket, > what would prevent another process from reading out the master password?) > >> > >> > >> It's in fact a unix domain socket file which is only accessible for the > owner of the key. ( Thanks for bringing this up, i forgot to flag the file > correctly - it's now fixed). > >> Relying on the file permissions in unix shouldn't be a problem, right? > >> > >> cheers & again - many thanks, > >> > >> Matthias > > > > You seem to be putting a lot of trust in facilities that are trivially > > exploitable to a determined attacker. For software like a password > > manager, assuming the kernel is secure is a poor security model. In > > addition to the existing attack surface, we live in a world where > > side-channel attacks are becoming more common, e.g., Spectre and > > Meltdown, so it isn't safe to assume the kernel or hardware are > > secure. A password manager needs to have a robust security model that > > has a minimal trust model if it is to be more than a toy. > > > > Just my $0.02 > > > > -- > > Christopher Nielsen > > "They who can give up essential liberty for temporary safety, deserve > > neither liberty nor safety." --Benjamin Franklin > > "The tree of liberty must be refreshed from time to time with the > > blood of patriots & tyrants." --Thomas Jefferson > > > > -- > > You received this message because you are subscribed to the Google > Groups "golang-nuts" group. > > To unsubscribe from this group and stop receiving emails from it, send > an email to golang-nuts...@googlegroups.com <javascript:>. > > For more options, visit https://groups.google.com/d/optout. > > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
