Protect .gpg-id

[Emile Cantin]

As Brian said, in that particular case, I think Alice and Bob should use a
repo where Eve doesn't have access, or at least write access.

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?

Emile

Le mer. 7 déc. 2016 à 11:05, Frank Grüllich <frank.gruellich at gmail.com> a
écrit :

> Hi,
>
> first things first: thanks for that wonderful and simple tool, I like it
> a lot!  It integrates so well into my daily work which happens to 90% on
> some kind of shell.  And I can throw all kind of stuff into it,
> passwords, certificates, RPMs, my favorite kitten images... just great.
>
> But now to serious business.  TL;DR: what prevents an attacker to
> manually mess around with .gpg-id files to make people encrypt secrets
> for private keys they own?
>
> Long story: that looks to me actually that simple that I cannot believe
> that there is no protection against it.  I looked into the mailing list
> archive for the last year but only found some vague hints into the
> direction (eg. signing .gpg-id files, but I don't really see how that
> could lead to anything).
>
> Let's assume Alice, Bob, and Eve work in a team "ABE" and need to share
> secrets with each other.  They have shared and imported all their GnuPG
> keys, trusted, signed, whatever.  They then did (something along):
>
>  % pass git init
>  % pass init -p teams/ABE/ alice bob eve
>  % pass insert teams/ABE/somesecret
>  % pass git push
>
> The usual stuff.  Now Alice and Bob want to start sharing their own
> little secrets (IOW they in addition have to work in another team "AB"
> excluding Eve).  Again:
>
>  % pass init -p teams/AB/ alice bob
>  % pass insert teams/AB/someothersecret
>  % ...
>
> However, Eve somehow does not like the situation and manually appends
> her key id to her copy of ~/.password-store/teams/AB/.gpg-id, commits
> and pushes it.  Alice or Bob pull that version, did not notice in the
> million of other updates that the .gpg-id file got updated and of course
> they also don't look at it, there could be 100's of IDs in it, why
> should they bother.  As soon as they insert or update secrets in their
> folder, Eve gets access to it.
>
> Am I right so far?  If so, any ideas how to prevent that?  Signing the
> file doesn't really help as Eve could easily create a signed version
> that Alice's and Bob's GnuPG would accept.  Maybe encrypting it?  That
> would be very incompatible with the current implemenation and it would
> remove the feature that someone can encrypt secrets for a group of
> people by only knowing their public keys.  Signing commits?  Does that
> help?  I don't know.
>
> Kind regards,
>  Frank.
> _______________________________________________
> 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/20161207/5db3ad4f/attachment.html>