> This means NOT storing your encrypted keys on a local device, but storing them in a (online) place where you can easily revoke access to.
This still requires trusting the user though. If a user *ever* had access to the plaintext credentials (which includes having access to them in an encrypted form that the user was capable of decrypting), you cannot reasonably consider them to be secured against misuse by that person, regardless of how well those credentials are subsequently protected. If you no longer trust them with those credentials (and a departed employee shouldn't be trusted in that manner), then the credentials *must* be changed. Any other approach just gives a false sense of security, and ultimately doesn't achieve the desired goal. If changing credentials is something that is really important to avoid for some reason, then an additional factor should be used to secure the system in question (e.g. password plus U2F token, TOTP code etc) - then when the user departs, you can lock out their token / invalidate their TOTP seed etc. and it no longer matters so much that they retain the password, because they still can't log in without compromising another user's 2FA who still has access. For the avoidance of doubt, please note that I'm talking about securing target systems using 2FA, *not* about securing the password store. Cheers, Steve 2019, 14:05 Jake Yip, <[email protected]> wrote: > > On Fri, Feb 22, 2019 at 9:37 AM higuita <[email protected]> wrote: > >> >> Of course i'm not talking about a malicious user directly, those can dump >> everything as plain text, it's more protecting "personal" backups and >> copies >> stored in other places that we may not trust in a long run. >> >> > This means NOT storing your encrypted keys on a local device, but storing > them in a (online) place where you can easily revoke access to. I have > found keybase and their keybase filesystem to work for me ( > https://keybase.io/docs/kbfs). > > >> Maybe pass could generate a key that expires after x days and double >> encrypt >> everything using first the key with the expiration date and then the user >> key. >> A small deamon (or even a cron) could keep the expiration key valid by >> generating >> a new one and reencrypt. Users that still have access can do a git pull >> and >> get the updated info. Users that fail to update will be unable to decrypt >> the >> content after the key was expired. >> >> Pass could remove the expired key automatically if expired, to avoid the >> faketime >> loophole of timetravel back to when the key was still valid. >> > > It works similarly to your double encrypt idea. The encrypted pass files > on KBFS is encrypted again with a device specific key. The pass files are > streamed to your machine and decrypted when needed. You can revoke a device > and it will not be able to get the encrypted pass files anymore. > > Regards, > -- > Jake Yip > DevOps Engineer > M +61 383 443 669 <+61+383+443+669> > [email protected] <[email protected]> > ardc.edu.au <http://www.ardc.edu.au> > [image: ardc.edu.au] <http://ardc.edu.au> > <https://twitter.com/ands_nectar_rds> > <https://www.youtube.com/user/andsdata> > ARDC acknowledges the Traditional Owners of the lands > that we live and work on across Australia and pays its respect > to Elders past and present. > Please consider the environment before printing this e-mail. > _______________________________________________ > Password-Store mailing list > [email protected] > https://lists.zx2c4.com/mailman/listinfo/password-store > -- Cheers, *Steve Gilberd* Erayd LTD *·* Consultant *Phone: +64 4 974-4229 **·** Mob: +64 27 565-3237* *PO Box 10019, The Terrace, Wellington 6143, NZ*
_______________________________________________ Password-Store mailing list [email protected] https://lists.zx2c4.com/mailman/listinfo/password-store
