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 <[email protected]> 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 > [email protected] > https://lists.zx2c4.com/mailman/listinfo/password-store >
_______________________________________________ Password-Store mailing list [email protected] https://lists.zx2c4.com/mailman/listinfo/password-store
