Protect .gpg-id

Frank Grüllich frank.gruellich at gmail.com
Wed Dec 7 17:04:33 CET 2016


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.
-------------- 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/20161207/c20414c2/attachment.asc>


More information about the Password-Store mailing list