user gone and expiring access

[Steve Gilberd]

This is IMO really out of scope. The only way to be sure the user doesn't
have a usable copy of the passwords, is to change the passwords. GPG
doesn't have any DRM mechanism that allows you to render something
un-decryptable after a certain date, and even if it did, I wouldn't
recommend trusting it - such things are far too easy to circumvent.

I am strongly opposed to the addition of any such feature to pass, because
of the false sense of security it may provide to users who don't understand
the risk.

Cheers,
Steve

On Fri, 22 Feb 2019, 11:32 higuita, <higuita at gmx.net> 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
>
> --
> Naturally the common people don't want war... but after all it is the
> leaders of a country who determine the policy, and it is always a
> simple matter to drag the people along, whether it is a democracy, or
> a fascist dictatorship, or a parliament, or a communist dictatorship.
> Voice or no voice, the people can always be brought to the bidding of
> the leaders. That is easy. All you have to do is tell them they are
> being attacked, and denounce the pacifists for lack of patriotism and
> exposing the country to danger.  It works the same in every country.
>            -- Hermann Goering, Nazi and war criminal, 1883-1946
> _______________________________________________
> 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/75356577/attachment-0001.html>