Protect .gpg-id

[Frank Grüllich]

On Wed, Dec 07, 2016 at 05:18:30PM +0000, Brian Candler wrote:
> On 07/12/2016 16:52, Emile Cantin wrote:
> > I think the key here is that 'pass init' reads and re-encrypts
> > everything with the new key(s), but Eve didn't actually use 'pass init'
> > but did it manually (because she can't read the files). This leads to a
> > situation where files in the directory are encrypted with a different
> > set of keys than the ones present in .gpg-id, which might be detectable.
> > Perhaps we can try to detect that kind of situation and throw a big
> > nasty warning in these cases?
> Interesting idea. Simplest option: whenever re-encrypting an existing file
> (either via 'pass init' or via 'pass edit'), check if the set of keys it was
> previously encrypted to is different to the new set.
> 
> I suppose it would still be possible for Eve to:
> 
> - update .gpg-id to point to A/B/E
> - put in a dummy (e.g. blank) password file, encrypted with A/B/E
> - hope that the next time A or B accesses it they think that the empty file
> was a bug, and replaces it with the correct password??

It also does not cover new secrets as there is nothing yet to compare
against.

One could make pass to check all secrets (in a certain path) against the
.gpg-id file they are supposed to use, something like "pass fsck [-p
some/path]".  I'm not sure if that's doable and also quite brute-force.
And Eve could still replace all files with dummy files encrypted with
the "right" keys.  She whould introduce quite a massive change to the
repo then which would probably get deteced easier.  But I'm still not
sure if I like the idea.

Thinking...
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 213 bytes
Desc: not available
URL: <http://lists.zx2c4.com/pipermail/password-store/attachments/20161208/f9a243ba/attachment.asc>