user gone and expiring access

[Lars Flitter]

Hi higuita,


with the architecture of pass there is really nothing you can do to
prevent the user that is in the possession of the gpg key to access the
keys prior to re-encryption.

This is because pass is so simple and that is what makes it great.

The best option you would have is for the user not to have the gpg key
anymore. On hardware tokens like the yubikey you can generate the gpg
key without the possibility to copy the key from the device. Now when
the user leaves, simply collect his yubikey and you know he will not be
able to decrypt the passwords. The only loophole for the malicious user
would be to "loose" the yubikey.


Best regards,

Lars


On 2/21/19 11:31 PM, higuita wrote:
> Hi
>
> Recently we got one user that left and, of course, we removed his key from the 
> gpg-id and re-encrypted everything. We also removed his github account. 
> All fine, future changes are safe... but nothing stops the user from having 
> a copy of the store and gpg key and still accessing the keys.
>
> How to solve this problem, remove access from someone that left.
>
> 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.
>
> One solution could be forcing that pass git update at least once each X days...
> but with git account closed that could help only if we kept his account 
> enabled until there is a update
>
> Another solution could be require the access to the git account. If forbiden
> pass could block the access. This of course would be a option that one must
> enable and could not be disabled after.
>
> But either solution do not protect from using git to checkout previous commits
> and using gpg to access the old info to see if any of the passwords are still
> valid
>
> So a perfect solution would be lock the files time based.
>
> 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.
>
> So what would be the best solution to this? Expire all passwords requires a ton of
> work, it would be good if we had a alternative way to protect old pass 
> commits from access. A time bomb inside pass, or even better, gpg would be perfect
>
> Best regards
> higuita
>
>
> _______________________________________________
> Password-Store mailing list
> Password-Store at lists.zx2c4.com
> https://lists.zx2c4.com/mailman/listinfo/password-store
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.zx2c4.com/pipermail/password-store/attachments/20190221/7d13078e/attachment.html>