<div dir="ltr">Hi list,<br><div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Mar 19, 2014 at 8:15 AM, Siim Põder <span dir="ltr"><<a href="mailto:siim@p6drad-teel.net" target="_blank">siim@p6drad-teel.net</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi<br>
<br>
Good to hear that pass is getting some auditing attention :)<br>
<br>
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?<br>
</blockquote><div><br></div><div>One case I was thinking of is password swapping. Suppose you have a password for <a href="http://good.com">good.com</a>, and one for <a href="http://bad.com">bad.com</a>. If the attacker can swap the passwords, next time you'll try to log into <a href="http://bad.com">bad.com</a>, you'd be giving the attacker your password for <a href="http://good.com">good.com</a>. 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.<br>
</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
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:<br>
1) Changed repo contents do end up being queried (on a different machine)<br>
2) Attacker can't just snoop on local gpg invocations (there aren't any)<br>
<br>
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.<br></blockquote><div><br></div><div>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.<br>
<br>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).<br>
<br></div><div>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.<br>
<br></div><div>Cheers,<br>Alfredo<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Siim Põder<br>
<div><div class="h5"><br>
"Jason A. Donenfeld" <<a href="mailto:Jason@zx2c4.com">Jason@zx2c4.com</a>> wrote:<br>
<br>
>Hi folks,<br>
><br>
>Alfredo Pironti, CCd, has written me to point out two issues in pass.<br>
>The first is that he believes gpg compression might reveal information<br>
>relating to the entropy of the enclosed password. Commit 51f9b6888<br>
>fixes this.<br>
><br>
>The second is something I've known about and considered for a long<br>
>time, which is that an attacker can swap out a gpg'd password with a<br>
>different one, or rename and/or delete passwords, because we only<br>
>encrypt but do not sign incoming passwords or filesystem information.<br>
>Apparently this is a big enough deal that a LaTeXified paper is being<br>
>submitted to a conference about it. The response toward this which I'm<br>
>leaning is that folks who desire tamper-proof password stores should<br>
>use the "gpg-sign" option of git-commit, along with hooks for<br>
>verification. Thoughts?<br>
><br>
>Jason<br>
</div></div>>_______________________________________________<br>
>Password-Store mailing list<br>
><a href="mailto:Password-Store@lists.zx2c4.com">Password-Store@lists.zx2c4.com</a><br>
><a href="http://lists.zx2c4.com/mailman/listinfo/password-store" target="_blank">http://lists.zx2c4.com/mailman/listinfo/password-store</a><br>
><br>
</blockquote></div><br></div></div></div>