On 07/12/2016 16:04, Frank Grüllich wrote:
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?
Not much.
However there is a variation of this problem which has bitten me
recently: a person in the team overwrites .gpg-id with just their own
key, then re-encrypts everything and commits back (*). The passwords
are then readable by them but not anyone else :-(
This is rather too easy to break. The solution is either to rewind the
repo, or to get the person who caused the problem to re-run 'pass init'
with the correct set of keys and commit again.
I suspect the simplest way to prevent this is to have a server-side
update hook which blocks all commits that update .gpg-id files. This
restriction can be temporarily removed whenever it's necessary to change
these files - or restricted to commits just from a trusted administrator.
Regards,
Brian.
(*) I think what happened was that he was missing the necessary public
keys for the other members of the team, and so did 'pass init <hiskey>'
as a way to "fix" the problem.
It would also be helpful if `pass init` were to warn loudly if there is
an existing .gpg-id file, which contains any keys that are not in the
list of keys provided on the pass init command line.
_______________________________________________
Password-Store mailing list
[email protected]
https://lists.zx2c4.com/mailman/listinfo/password-store
