Exactly - and systems do not typically have this - yet are considered secure. If the plain text is ever available - and it almost always is (in the original input component, etc.) it is always subject to attack/hack - and as far as I am aware without hardware support (dongle, etc.) this is a limitation of all security implementations.
You don’t always need the plain text though, you can store the one way hash (as in Http Digest security), and use that, so if the store is compromised the users known passwords are not discovered - but it doesn’t mean access won’t be granted. As far as I know - even ‘keychain access’ in osx (used in millions of systems) would be subject to similar hack to if root was available and memory could be scanned. > On Oct 15, 2018, at 4:58 PM, Christopher Nielsen <m4dh4t...@gmail.com> wrote: > > On Mon, Oct 15, 2018 at 2:17 PM robert engels <reng...@ix.netcom.com > <mailto:reng...@ix.netcom.com>> 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 <m4dh4t...@gmail.com> >>> wrote: >>> >>> On Mon, Oct 15, 2018 at 1:28 PM Matthias Schmidt >>> <matthias.schm...@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 > > Not sure how you expect the password to not be stored in memory in > plaintext at some point. Without a secure hardware coprocessor with > secure memory, the system is still susceptible to at least > side-channel and potentially timing attacks. > > -- > 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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
