Hi Burak, and thanks pointing to you work. The memory-pinning was rather easy to integrate, have a look:
https://github.com/ms140569/loki/commit/ad02ac092e56d4ac96ffaf8b737dac515516abfe Timing-out the key-agent is something which came to my mind as well - i guess i'll do it optionally. cheers, Matthias Am Donnerstag, 18. Oktober 2018 15:32:28 UTC+2 schrieb Burak Serdar: > > On Tue, Oct 16, 2018 at 1:55 PM Matthias Schmidt > <matthias...@gmail.com <javascript:>> wrote: > > > > And here it is: > > > > https://github.com/ms140569/loki/releases/tag/1.2.0 > > > Thanks for sharing this. I find this interesting because I've been > working on a very similar idea for an OIDC token manager CLI, and came > up with almost the same scheme regarding how you used the domain > sockets and the agent. I used rpc instead of a raw protocol though, > and the agent times out after a while in my case. You can take a look > at https://github.com/bserdar/took the crypto rpc stuff is under > crypta package. > > It does suffer from the same problems mentioned in this thread: if you > can scan the memory, the master key is there. I'll add memory locking > to mine. > > > > > Thanks to your guy's input the key-agent should be now way more secure. > > > > cheers, > > > > Matthias > > > > Am Dienstag, 16. Oktober 2018 20:31:42 UTC+2 schrieb Matthias Schmidt: > >> > >> Hi Christopher + Eric, > >> > >> thanks for your feedback. You are right, i really underestimated the > risk of such attacks. > >> > >> I will lock the key-holding memory in the next release. > >> > >> cheers, > >> > >> Matthias > >> > >> > >> Am Montag, 15. Oktober 2018 23:13:32 UTC+2 schrieb Christopher Nielsen: > >>> > >>> On Mon, Oct 15, 2018 at 1:28 PM Matthias Schmidt > >>> <matthias...@gmail.com> 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.
