Protect .gpg-id
Emile Cantin
emilecantin at gmail.com
Wed Dec 7 17:52:59 CET 2016
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>
More information about the Password-Store
mailing list