user gone and expiring access

[Steve Gilberd]

> 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, <jake.yip at ardc.edu.au> wrote:

>
> On Fri, Feb 22, 2019 at 9:37 AM higuita <higuita at gmx.net> 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>
> jake.yip at ardc.edu.au <tsuey.cham at ardc.edu.au>
> 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
> Password-Store at lists.zx2c4.com
> 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*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.zx2c4.com/pipermail/password-store/attachments/20190222/9e9f10ba/attachment-0001.html>