[pass] GPG Compression and Authenticity

[Alfredo Pironti]

Hi list,

On Wed, Mar 19, 2014 at 8:15 AM, Siim Põder <siim at p6drad-teel.net> wrote:

> Hi
>
> Good to hear that pass is getting some auditing attention :)
>
> I'm struggling to find a situation where signing would help significantly.
> If an attacker can modify the store, they will be able to deny you access
> to any of the passwords. In which case would it be more useful for them to
> provide a wrong password? For a social engineering attack? To get an
> account to lock?
>

One case I was thinking of is password swapping. Suppose you have a
password for good.com, and one for bad.com. If the attacker can swap the
passwords, next time you'll try to log into bad.com, you'd be giving the
attacker your password for good.com. You're right that denial of service is
always a possibility, and I don't see a trivial way to prevent it if the
attacker can erase content on your hard drive.


>
> It also seems that it would be somewhat rare to have a pass repo that is
> *pulled* from as this is the only case I can think of where this attack
> isn't shadowed by a complete compromise:
> 1) Changed repo contents do end up being queried (on a different machine)
> 2) Attacker can't just snoop on local gpg invocations (there aren't any)
>
> With this in mind (unless there is a more serious threat I'm overlooking
> or a dead-simple fix in pass) your suggestion sounds appropriate.
>

Using git-level signature ensures integrity of the data on the remote
repository, but not of the local data. Hence, you get protection from
attackers controlling a git repository, but not from attackers being able
to write into your home directory. If you want to protect also from local
attackers, then pass-level signature seems to be required.

Arguably, local and remote attackers constitute two different kinds of
threats. Jason's git-level signature solution seems a reasonable trade-off
between ease and transparency of implementation, and offered protection --
namely against remote attackers. A more "paranoid" approach may alter the
database structure to also offer protection against local attackers
(requiring a brute-force of the private key passphrase for local attackers).

I don't have a strong opinion on which solution to go for -- but if I were
to vote, I'd prefer protection against both local and remote attackers.
Anyway, what I really think is important is to agree and document what the
expected threat model is (e.g.: "if you have a local attacker, we consider
you doomed anyway, and hence pass provides no protection"), and to
implement fixes accordingly.

Cheers,
Alfredo


> Siim Põder
>
> "Jason A. Donenfeld" <Jason at zx2c4.com> wrote:
>
> >Hi folks,
> >
> >Alfredo Pironti, CCd, has written me to point out two issues in pass.
> >The first is that he believes gpg compression might reveal information
> >relating to the entropy of the enclosed password. Commit 51f9b6888
> >fixes this.
> >
> >The second is something I've known about and considered for a long
> >time, which is that an attacker can swap out a gpg'd password with a
> >different one, or rename and/or delete passwords, because we only
> >encrypt but do not sign incoming passwords or filesystem information.
> >Apparently this is a big enough deal that a LaTeXified paper is being
> >submitted to a conference about it. The response toward this which I'm
> >leaning is that folks who desire tamper-proof password stores should
> >use the "gpg-sign" option of git-commit, along with hooks for
> >verification. Thoughts?
> >
> >Jason
> >_______________________________________________
> >Password-Store mailing list
> >Password-Store at lists.zx2c4.com
> >http://lists.zx2c4.com/mailman/listinfo/password-store
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.zx2c4.com/pipermail/password-store/attachments/20140319/c9b46942/attachment.html>