Re: Confirmation for cached passphrases useful?
On Monday 18 October 2010, Faramir wrote: El 17-10-2010 22:09, Doug Barton escribió: On 10/17/2010 5:43 PM, Faramir wrote: |That may be true. However, remember feeling secure is part of |security | | too, so if that feature doesn't break anything, and make people | sleep better... Two problems with that theory. The first is that a false sense of security does more harm than good. The second is that there is no such thing as a zero-cost change to software. So any proposed change has to have benefits that outweigh the costs. Of course accurately anticipating those costs is a whole different category of problems. :) Right, I agree, we don't want those stones that keeps tigers away. But as long as people know the feature may be ignored by malware, it wouldn't be false sense of security, maybe it would be the solution against false sense of insecurity (if such thing exist). Also, I was not saying anything about costs of adding the feature, so my message should have said: if there is a developer willing to add it, and it doesn't break anything, and it can be disabled by user, I'm ok with it. Please note I'm not requesting that feature, I just said I would not oppose to it's addition. The feature might not break anything now but it will make the software more complex. More complex software tends to break more easily. One of the main design goals of gpg-agent, pinentry, etc., was to keep the code of those small helper applications dealing with the secret keys and the passphrases as simple as possible to avoid the complexity trap. Also, it's a popular fallacy that adding a feature generates cost only once. Every new feature will increase the maintenance costs and thus generate additional cost for the whole lifetime of the software. Regards, Ingo signature.asc Description: This is a digitally signed message part. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Confirmation for cached passphrases useful?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 El 15-10-2010 14:31, Doug Barton escribió: On 10/15/2010 9:23 AM, Werner Koch wrote: Nevertheless, the confirmation prompt for a cached passphrase is not entirely unfounded ... The other problem with the confirmation proposal is that (unless I'm missing something really dramatic) the intersection between plausible attack vectors and vulnerabilities that confirmation would actually fix seems so small that it does not justify even the coding/QA time to develop the feature, never mind the inconvenience to the user. I guess as long as it can be disabled by people thinking it is useless/too annoying, it won't cause problems... Best Regards -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBCAAGBQJMu5bbAAoJEMV4f6PvczxAiOEIAI0JBQ47kWOjw6tnidtBDgQJ FmLo/Xo9sxrKVq2JhxQPtYn1zlswZiYOZubCR070Yz9mO8Bx4CbkuwAS/XbsfFav ciUuoB5cwh+Vkhj+U4S2KWO5NCdEhTYmrgNZ9ZR66WH6qygHHt2DkPjCxmWXMALW OKvO52LXrjCnF+I+DtY2nfBjepYGjQatAntitzUTORz33Ggq/Q2I5UmGB8DEu1q2 ezmK9Zf8q5xMMx9Vwgt7ZN/Y9bF/VUVdGg7Y9Px4e/KbCSVTbHShlMpN8M+rthD/ iLNFnA2YK8ZBJqnbuEGvzyjx/NaJUHRryGIxZZTKJvn6Hmr9xgVcOCnUDXqkpkM= =7+qH -END PGP SIGNATURE- ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Confirmation for cached passphrases useful?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 El 15-10-2010 20:29, Jameson Rollins escribió: No, I was just curious why, if you were an ssh-agent user, you would be ok with the implementation there but not for gpg-agent. If you're not an ssh-agent user then you have nothing to get defensive about. Lets say I buy a house, and the house has elephant proof fences. Since it didn't made the price too expensive, I'm ok with that. And since it doesn't bother me, I don't need to remove them. But now I buy another house, and somebody says hey, this house lack of elephant proof fences, will you add them?. My answer would be no, there are not elephants in this country, so there is no need to spend money and time building something I don't need. If a developer already added a feature to some software, well, there is no need to complain. The thing is: should GnuPG developers spend time in adding a new feature? I'm not a developer, so whatever they chose is ok for me, as long as they don't break anything. Best Regards -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBCAAGBQJMu5pVAAoJEMV4f6PvczxA4rUH/3V9SvwiFBmdYQQFpBIkFyAp EROf8aBPumPszHPavAR8vuize+58Vx1wrtjfEwNVYnUuAtNTAxQXrcP70x9Rrqj5 AItQyCo++3F32gLdMzO+4BKIVa5PlmOLi7eqkShCdGp7pHHWWUZLEnSDRb1LYvj4 NsgHMibDNkMNah6ntXKVvBg1omk9OeEanr1tsLv/15DfAVzEaFGhOo68Nr1+4R6A ZvGFn2RgHlaFEfIGCwe8Dy8C1/FpWcU68UcrJwlACZtiwpqp4ip623m5Fgro3rcG 1P81FrCDTaLLSbEMxAbimu20hTGm6ZX3j2FoLip7mP4Yf8IGP43kLJlFARclhWc= =q4c7 -END PGP SIGNATURE- ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Confirmation for cached passphrases useful?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 10/17/2010 5:43 PM, Faramir wrote: | |That may be true. However, remember feeling secure is part of security | too, so if that feature doesn't break anything, and make people sleep | better... Two problems with that theory. The first is that a false sense of security does more harm than good. The second is that there is no such thing as a zero-cost change to software. So any proposed change has to have benefits that outweigh the costs. Of course accurately anticipating those costs is a whole different category of problems. :) Doug - -- Breadth of IT experience, and| Nothin' ever doesn't change, depth of knowledge in the DNS. | but nothin' changes much. Yours for the right price. :) | -- OK Go http://SupersetSolutions.com/ -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.14 (MingW32) iQEcBAEBCAAGBQJMu55cAAoJEFzGhvEaGryErNUH/iUNcxZJCLG93g7GuaKpZK5A Ef68JxFHHrlVqlhCsFaAWbkCgYqmJp+z5PqxUbxE7zoJojXcVNnm0GaSfuhwKVp1 nyVOZwa60C0OH+9eCE29hYh3/Bn+IbzYnBvzg23cYBcfl0wi7JbJNdxlbvRpWsB2 CeTIOhUx9auF/Bya1qrC4HIga4zcdKRJp5qL59AdiQxBJhyUIDM3d8E+g2GPYWqO WV8ZjuC8bOLPCoCHTz9957+HQqiHRtGF33cTvNokzO7SaK0UCCZ3UXkD0RKY69CS WpvY08K/rKoI7bHPSa0oCQuX06mosdgFAwJtfAGxaQe7j5O9hn2/EGP+Mw9MgYE= =S7zO -END PGP SIGNATURE- ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Confirmation for cached passphrases useful?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 El 17-10-2010 22:09, Doug Barton escribió: On 10/17/2010 5:43 PM, Faramir wrote: | |That may be true. However, remember feeling secure is part of security | too, so if that feature doesn't break anything, and make people sleep | better... Two problems with that theory. The first is that a false sense of security does more harm than good. The second is that there is no such thing as a zero-cost change to software. So any proposed change has to have benefits that outweigh the costs. Of course accurately anticipating those costs is a whole different category of problems. :) Right, I agree, we don't want those stones that keeps tigers away. But as long as people know the feature may be ignored by malware, it wouldn't be false sense of security, maybe it would be the solution against false sense of insecurity (if such thing exist). Also, I was not saying anything about costs of adding the feature, so my message should have said: if there is a developer willing to add it, and it doesn't break anything, and it can be disabled by user, I'm ok with it. Please note I'm not requesting that feature, I just said I would not oppose to it's addition. Best Regards -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBCAAGBQJMu77zAAoJEMV4f6PvczxAixsH/2eOUTAxT6NRjNkknkUPX3B9 C6smHbt7s3pQOdRGsEMwzuF6/IvcFAIs/wiO9ouKpaJed3xWjqPYL9BCOmpSfDDT 1gTfYXjE8fRAgy6z+Otj5JHSAOVHPJWGDYtYTz/JjH23R7sx6QTOXikW5Yct6McU 0gP1NWLQElp1t0SIwzldSCFFmCVX2PSU6MTD24ZTYfnWS4PwQNg8C/DHbyK+94I4 K6nr18Bi+cfHbC4sPRGuXkDAStkEW+sHn2udPCn3fNX17lQKsZbJgRUH3eEByLj2 Guwv8wD2hvM920X3Yj+5NtmVnpke+af+bKMbM6o+nHEhvNMC6QUwn5sqB/L86cY= =YyM0 -END PGP SIGNATURE- ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Confirmation for cached passphrases useful?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 El 17-10-2010 23:47, Robert J. Hansen escribió: ... And if one day the user finds it has been disabled somehow, the user might become aware of some malware in the machine... By this logic every user should have a big piece of Scotch tape on the center of his or her screen. If the piece of tape is ever missing, then you know someone's been tampering with your machine. Yes, something like that. That's why I installed something supposed to warn me if a unknown process tries to communicate with another process. If it works as expected, I would get a warning about trojan.exe trying to access Agent, and I would have to chose between blocking it, allowing it, and making a rule from my decision to prevent future warnings about the same thing. I'm not requesting that feature, I don't need it, but it won't bother me if somebody decides to implement it, as long as it can be disabled. Also, since software is always changing, many times in annoying ways (I'm _not_ talking about GnuPG), probably soon or latter I'll have to get used to a confirmation screen where there was none in the previous version. I think I won't participate in _this_ discussion anymore, since I already said I'm neutral about that feature, and don't have anything to say that might be valuable to the discussion. Best Regards -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBCAAGBQJMu8KSAAoJEMV4f6PvczxAyxoH/RJMkGI6Z8AvO8/hdrAC1rgG tIqlV3IIk4EamOnIEFbEV7E2K8QiY3W7kjx30i1ELe+jfStfpgG70gpuYI3ZgODw GjaVI2eiZcjOrtkQ+ToSlyVrlf5IY196kvMgpyda+ARZQNCMcu015rhz0RIC0P/5 TZcu2z+mfwbxOr3UYSau9xzd4EI8ivjFroh+SpaysPw0JkFKtAndCmzXLOqH5eH5 VArfiqDPBjdExxzaT3iInfHrJPZCuSlfwIwNK6n252LCkruf+tdoykYEC/2CrvI7 4rQJPTmGXca+98YgRpdFXxbf7o7gGjwI/vF1+HvlS4C1o4990DyYvZ8itDKBXPM= =mrQ+ -END PGP SIGNATURE- ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Confirmation for cached passphrases useful?
On Wed, 13 Oct 2010 17:51, d...@fifthhorseman.net said: If i run the agent locally, and forward access to it to a constrained account, then the constrained account (which is talking to the agent) *does not* have the ability to simulate such X11 events. You mean to a different X server? For example from a nested one to the main X server? Then why do you want to have this yes/no prompt, the other X server has no access to the pinentry. I doubt that it is possible to have a restricted account running on the same X server. requires, say, an ACPI event, or a special keypress (not an X11 event) from a designated hardware button. in that case, malicious code with access to the X11 session could detect that a prompt had been made, and If there is malicious code running on your machine with access to resources under your control, I can only say: game over. No external button will help you here. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Confirmation for cached passphrases useful?
Am Freitag 15 Oktober 2010 12:28:33 schrieb Werner Koch: If there is malicious code running on your machine with access to resources under your control, I can only say: game over. No external button will help you here. That's why we try to restrict the access of malicious code, isn't it? Following your pessimistic attitude there would hardly be any reason not to work as root. Hauke -- PGP: D44C 6A5B 71B0 427C CED3 025C BD7D 6D27 ECCB 5814 signature.asc Description: This is a digitally signed message part. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Confirmation for cached passphrases useful?
On Thu, 14 Oct 2010 20:03, sascha-ml-reply-to-201...@silbe.org said: One instance where the proposed mechanism (in conjunction with the new version of gpg-agent that will handle the secret keys itself) would be Just for the records: This is no new mechanism of the agent. It is in use for about 8 years now. The change is that GPG uses this mechanism now, in the past only GPGSM and the the ssh-agent support in gpg-agent used it. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Confirmation for cached passphrases useful?
On Fri, 15 Oct 2010 12:55, mailinglis...@hauke-laging.de said: Following your pessimistic attitude there would hardly be any reason not to work as root. Nope. Not working under root is important to keep the system stable and provide access restrictions to the non-malicious users. OTOH, it is hard enough to close all remotely exploitable bugs. Given the constant proliferation of local privilege escalation bugs, it seems to me not possible for the majority of systems to keep them *all* closed. Look only on how many admins are proud of their system's uptimes and check for example the list of severe Linux bugs. If you want to protect your keys, use a smartcard or a second box acting similar to a smartcard. Nevertheless, the confirmation prompt for a cached passphrase is not entirely unfounded given that we have quite some feature in gpg-agent which are more questionable (e.g. the whole passphrase quality checking stuff). Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Confirmation for cached passphrases useful?
On 10/15/2010 9:23 AM, Werner Koch wrote: Nevertheless, the confirmation prompt for a cached passphrase is not entirely unfounded I've really been biting my tongue on this thread because it seemed like the right people were saying the right things already, but you're making me nervous now Werner. :) The right solution to the concern expressed is to keep the time for gpg-agent to cache the pass phrase down to a reasonable level, where reasonable may mean different things in different environments. I don't remember what the default is, but I do recall thinking when I first installed -agent that it seemed sufficiently short to protect new users from themselves; but too short for my tastes, so I fixed it. :) The other problem with the confirmation proposal is that (unless I'm missing something really dramatic) the intersection between plausible attack vectors and vulnerabilities that confirmation would actually fix seems so small that it does not justify even the coding/QA time to develop the feature, never mind the inconvenience to the user. hth, Doug -- Breadth of IT experience, and| Nothin' ever doesn't change, depth of knowledge in the DNS. | but nothin' changes much. Yours for the right price. :) | -- OK Go http://SupersetSolutions.com/ ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Confirmation for cached passphrases useful?
On 10/15/10 1:31 PM, Doug Barton wrote: The other problem with the confirmation proposal is that ... the intersection between plausible attack vectors and vulnerabilities that [this proposal] would actually fix seems [very] small. I seem to recall saying something similar to this a few days ago. :) I'll go one step further: so far I haven't seen anyone present a plausible intersection. I've seen some hypothetical intersections, but none that I think are plausible. This seems like a nonsolution to a nonproblem. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Confirmation for cached passphrases useful?
On 10/15/10 2:49 PM, Jameson Rollins wrote: Without use confirmation in the agent, a malicious program running under your account could access your secret key without you knowing it. This can still happen with a confirmation prompt. Confirmation cannot protect against malware running under your account. If the agent pops up a dialog box, then all I have to do is intercept the dialog box and answer 'yes.' ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Confirmation for cached passphrases useful?
Ok, then this protects against malicious programs that are not intercepting the dialog box. Which means that six months after this feature gets implemented, the malware authors will write exploits that intercept the dialog box. Arms races are inevitable, but stupid arms races should be avoided. Don't let the perfect be the enemy of the good. I'm not. This idea isn't good. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Confirmation for cached passphrases useful?
On 10/15/10 5:04 PM, Jameson Rollins wrote: Don't let the perfect be the enemy of the good. But is it good? To me this feature seems like security theater. It makes you feel all warm and fuzzy and lets you sleep at night, but doesn't provide any real protection. Is it good to have users thinking that there's no way their box can be compromised, because they're not getting pop-ups, when in reality they may be completely compromised? Do the percieved protections of this feature come anywhere close to the actual protection provided? -- Grant I am gravely disappointed. Again you have made me unleash my dogs of war. signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Confirmation for cached passphrases useful?
On Fri, 15 Oct 2010 18:23:04 -0400, Robert J. Hansen r...@sixdemonbag.org wrote: I'm not. This idea isn't good. Do you use ssh-agent? Do you think their implementation of the same thing is not good? If so, have you complained to them about it, or asked why the implemented it? jamie. pgph0M2eECPqg.pgp Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Confirmation for cached passphrases useful?
Am Samstag 16 Oktober 2010 00:23:04 schrieb Robert J. Hansen: Ok, then this protects against malicious programs that are not intercepting the dialog box. Which means that six months after this feature gets implemented, the malware authors will write exploits that intercept the dialog box. Arms races are inevitable, but stupid arms races should be avoided. This implies the strange claim that it will forever be possible to do that. As I already mentioned you can run X clients untrustedly today and SELinux is going to be extended by features for X access restriction. But, of course, you can deny all applications that never use gpg keys access to both the files and the socket by means of the LSMs even today. And if an application gets hijacked that has to access the key files and the socket then an attacker can wait until the next intended operation occurs. So the user would not notice the abuse of his key. The process of informing the user could be more clever than a simple gpg- agent access, please click OK window. An obvious option is to allow the user to configure a program and allow or deny access based on the exit code; we saw proposals what such a check program could do here in the discussion. I just don't like the idea that access to the agent is not noticed by design. Somebody mentioned an inconvenience for the user. I would make this behaviour an option (for people understanding the merits and limits) not the default. Thus no inconvenience for anyone. Hauke -- PGP: D44C 6A5B 71B0 427C CED3 025C BD7D 6D27 ECCB 5814 signature.asc Description: This is a digitally signed message part. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Confirmation for cached passphrases useful?
Do you use ssh-agent? Do you think their implementation of the same thing is not good? If so, have you complained to them about it, or asked why the implemented it? This seems to be an argument from implication of hypocrisy: as if, were I a user of ssh-agent, my opinion regarding gpg-agent could be safely dismissed on the grounds of my hypocrisy by not bringing the same issues up to the ssh-agent authors. The answer to your questions are, no, I do not, I have not looked at it enough to have an informed opinion, and I reject out of hand all argument by implication of hypocrisy. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Confirmation for cached passphrases useful?
This implies the strange claim that it will forever be possible to do that. It does not. It states that at present the OS infrastructure we have makes implementing this a losing proposition. As soon as the OS infrastructure changes enough to make this a winner, then we should revisit this decision. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Confirmation for cached passphrases useful?
On Sat, 16 Oct 2010 01:05:11 +0200, Hauke Laging mailinglis...@hauke-laging.de wrote: I just don't like the idea that access to the agent is not noticed by design. I strongly agree with this point. Let's think about it another way: what if the user is themselves doing something that is unintentionally accessing the key? They might prefer to know about it rather than have it accessed without their knowledge. I would say that's good enough reason to have confirmation right there. jamie. pgpnVgCOCUNn9.pgp Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Confirmation for cached passphrases useful?
On Fri, 15 Oct 2010 19:12:21 -0400, Robert J. Hansen r...@sixdemonbag.org wrote: Do you use ssh-agent? Do you think their implementation of the same thing is not good? If so, have you complained to them about it, or asked why the implemented it? This seems to be an argument from implication of hypocrisy: as if, were I a user of ssh-agent, my opinion regarding gpg-agent could be safely dismissed on the grounds of my hypocrisy by not bringing the same issues up to the ssh-agent authors. No, I was just curious why, if you were an ssh-agent user, you would be ok with the implementation there but not for gpg-agent. If you're not an ssh-agent user then you have nothing to get defensive about. jamie. pgpP9szUlw4zT.pgp Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Confirmation for cached passphrases useful?
I strongly agree with this point. Let's think about it another way: what if the user is themselves doing something that is unintentionally accessing the key? Then that's the user's own problem. They're the one who decided to enable passphrase caching and to set a large timeout window. They get to make their decisions, and it's foolish of us to try to protect them from it. In fact, I would argue this feature would cause more problems than it claims to solve. The number of people who would benefit from it is relatively small. The number of people who discover their automated scripts no longer work would be large. No choice comes without consequences. This feature enhancement is no exception. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Confirmation for cached passphrases useful?
On 10/13/2010 07:02 PM, MFPA wrote: The user can type their password once per session into a text file and paste it every time it is requested. This reduces the annoyance factor and does not train the user to constantly re-type the passphrase. This strikes me as the worst suggestion on this thread so far. Please, do not store the passphrase to your secret key in the clear in a file on your computer, and do not suggest that other people do so. That's even worse than writing it on a post-it note and taping it to your monitor. Passphrases are your last line of defense against a compromise of your secret key material. --dkg signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Confirmation for cached passphrases useful?
also sprach MFPA expires2...@ymail.com [2010.10.14.0102 +0200]: The user can type their password once per session into a text file and paste it every time it is requested. This reduces the annoyance factor and does not train the user to constantly re-type the passphrase. That's a great idea. I have started work on a Facebook applet to automate this process, so that I can keep such vital information with everything else that I care about. Strangely appropriate, randomly selected quote below. -- martin | http://madduck.net/ | http://two.sentenc.es/ we are trapped in the belly of this horrible machine, and the machine is bleeding to death. -- godspeed you black emperor! spamtraps: madduck.bo...@madduck.net digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/) ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Confirmation for cached passphrases useful?
On 13/10/2010 4:02 PM, MFPA wrote: The user can type their password once per session into a text file and paste it every time it is requested. This reduces the annoyance factor and does not train the user to constantly re-type the passphrase. I use a program called KeePass to keep track of my passwords. It has a linux port called KeePassX, as well. It stores the password in an encrypted database and when the user requests it, copies it to the clipboard. After 20 seconds, the clipboard is cleared. KeePass can also be configured to lock the workspace after a certain period of time idle. signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Confirmation for cached passphrases useful?
Excerpts from Robert J. Hansen's message of Tue Oct 12 15:25:50 +0200 2010: These two attack modes (root and user access) cover the overwhelming majority of instances today, so already this hypothetical attack is an exotic. That most mainstream systems are painfully easy to attack doesn't imply we should stop trying to make systems more secure. One instance where the proposed mechanism (in conjunction with the new version of gpg-agent that will handle the secret keys itself) would be both useful and secure is Sugar [1] in combination with Rainbow [2]. Depending on who you believe, there are currently some hundred thousand to over a million systems currently running this combination (on OLPC [3] XO-1 [4]). Sascha [1] https://www.sugarlabs.org/ [2] http://wiki.laptop.org/go/Rainbow [3] http://www.laptop.org/ [4] http://wiki.laptop.org/go/XO-1 -- http://sascha.silbe.org/ http://www.infra-silbe.de/ signature.asc Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Confirmation for cached passphrases useful?
On 10/13/10 11:51 AM, Daniel Kahn Gillmor wrote: From a different perspective, i could run the agent itself in a constrained account, and replace the prompting tool with a tool that requires, say, an ACPI event, or a special keypress (not an X11 event) from a designated hardware button. in that case, malicious code with access to the X11 session could detect that a prompt had been made, and possibly dismiss it or hide it from the user, but could not force acceptance of the keypress without superuser access (at which point, game over anyway). To take a vulnerability from a malicious use of secret key material to a simpler denial of service attack strikes me as a move in the right direction. But ultimately once you start trying to fix the problem by offloading the checks to special hardware, you might as well just key a smart card reader with an integrated keypad. Then you can use a simple pin. Not quite as convenient as hitting Y/N, but way more convenient than a really strong password. -- Grant I am gravely disappointed. Again you have made me unleash my dogs of war. signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Confirmation for cached passphrases useful?
On 10/14/2010 04:31 PM, Grant Olson wrote: But ultimately once you start trying to fix the problem by offloading the checks to special hardware, you might as well just key a smart card reader with an integrated keypad. Then you can use a simple pin. Not quite as convenient as hitting Y/N, but way more convenient than a really strong password. Yes, that'd be nice, if that hardware is available and convenient for the user. But far more people have access to a laptop with system-handled ACPI key combinations than have access to card readers with integrated keypads. card readers with integrated keypads are also bulky, awkward to transport and use in mobile context, and tend to be significantly slower at performing secret-key operations than modern computers (laptop or desktop). card readers with integrated keypads are also additional points of failure, and have a non-negligible financial cost over and above the cost of the hardware on which to run GnuPG. Back to the original point: a confirmation prompt for the agent has the potential to be useful in many cases, particularly with the agent model described for the upcoming gnupg 2.1, and to a lesser extent with earlier versions of the agent protocol. I'm not denying that there are other approaches which might solve the same problem, but there are tradeoffs to all of them which may not be suitable for any particular user. I remain perplexed at the opposition this reasonable feature proposal has received. Regards, --dkg signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Confirmation for cached passphrases useful?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi On Thursday 14 October 2010 at 3:18:47 PM, in mid:4cb71147.5090...@fifthhorseman.net, Daniel Kahn Gillmor wrote: This strikes me as the worst suggestion on this thread so far. Please, do not store the passphrase to your secret key in the clear in a file on your computer, and do not suggest that other people do so. It was a non-serious suggestion of a simple, albeit obviously insecure, way to overcome the two issues you mentioned in your previous posting (about re-typing the passphrase each time the secret key gets used being annoying and potentially insecure). As Dan Cowsill points out, there are password managers available that allow the user to copy/paste their passphrase in much the same way but store it in an encrypted database. [ That's even worse than writing it on a post-it note and taping it to your monitor. That would depend on your threat model... - -- Best regards MFPAmailto:expires2...@ymail.com Another person's secret is like another person's money: you are not as careful with it as you are with your own -BEGIN PGP SIGNATURE- iQCVAwUBTLd9IKipC46tDG5pAQo5FQP8CuVxi8krMIFKMC3IaGRhaq/D4MJj/oC7 q7o0aZImA+/6pK5j77J4vo5WmPVfCK8lVUvEY8V9J0lYVjKcTtPHYiczrVdj08Ys qaB3ZC3pvtnGNq2v8eXoSqUwU+IbR5br7Dqwk2DO3e57fE4vaaAZqraCxAc3E0AN AepG+OFrsGg= =r9kT -END PGP SIGNATURE- ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Confirmation for cached passphrases useful?
Am Dienstag 12 Oktober 2010 04:44:41 schrieb Daniel Kahn Gillmor: (e.g. one process can send a simulated mouseclick to another process pretty easily) I am not familiar with X details (let alone that other one OS). Does grabbing the mouse prevent other processes from knowing where the click occurs? You could use a dialog differen from just an OK button. You could display a ten times ten array and the user hat to click a certain number. This is similar fast to clicking the OK button and easy to remember (always the same number) but makes abuse improbable (of course, that is not the level of probability we usually have when attacking gpg...). If other processes cannot read the content of the dialog window then other means are possible: Use a blank area with a randomly positioned mark to click on. And react to failures. Hauke -- PGP: D44C 6A5B 71B0 427C CED3 025C BD7D 6D27 ECCB 5814 signature.asc Description: This is a digitally signed message part. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Confirmation for cached passphrases useful?
On Thu, October 14, 2010 4:54 pm, Daniel Kahn Gillmor wrote: On 10/14/2010 04:31 PM, Grant Olson wrote: But ultimately once you start trying to fix the problem by offloading the checks to special hardware, you might as well just key a smart card reader with an integrated keypad. Then you can use a simple pin. Not quite as convenient as hitting Y/N, but way more convenient than a really strong password. Yes, that'd be nice, if that hardware is available and convenient for the user. But far more people have access to a laptop with system-handled ACPI key combinations than have access to card readers with integrated keypads. This reminds me of the Yubikey, which is a one-button USB stick that registers as a keyboard, and types your password when you press the button on it. In other words, you don't necessarily need there to be a /physical/ keypad for a device to act like it has a keyboard. IIRC this wasn't the particular use case meant for the Yubikey though -- I think it was meant to be used in combination with online sites. There might be a similar device meant for GPG... or one could be made if it doesn't exist yet. Anything beats copying a password to a plaintext file, which is insane. Seems to beg a Spaceballs quote: 12345? I've got the same password on my luggage! Oh... and change the password on my luggage. ... Back to the original point: a confirmation prompt for the agent has the potential to be useful in many cases, particularly with the agent model described for the upcoming gnupg 2.1, and to a lesser extent with earlier versions of the agent protocol. I'm not denying that there are other approaches which might solve the same problem, but there are tradeoffs to all of them which may not be suitable for any particular user. I remain perplexed at the opposition this reasonable feature proposal has received. I think it reminds some people of an Are you sure? prompt. I realize that's not exactly meant to be what this is for, of course, but that might ultimately be what it feels like unless there's another outward purpose for the prompt. Now, that said, I'll just say I'm not against adding it if there's a particular security case deemed worth defending. -- Chris -- Chris Knadle chris.kna...@coredump.us ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Confirmation for cached passphrases useful?
On 10/12/2010 02:46 PM, Werner Koch wrote: Anyway, if you are already have these permissions you can attack the keys with all kind of simple tricks. Thus it is mood. i'm not convinced it's moot, especially if i understand the model you're advancing for the agent for 2.1 correctly. If i run the agent locally, and forward access to it to a constrained account, then the constrained account (which is talking to the agent) *does not* have the ability to simulate such X11 events. From a different perspective, i could run the agent itself in a constrained account, and replace the prompting tool with a tool that requires, say, an ACPI event, or a special keypress (not an X11 event) from a designated hardware button. in that case, malicious code with access to the X11 session could detect that a prompt had been made, and possibly dismiss it or hide it from the user, but could not force acceptance of the keypress without superuser access (at which point, game over anyway). To take a vulnerability from a malicious use of secret key material to a simpler denial of service attack strikes me as a move in the right direction. --dkg signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Confirmation for cached passphrases useful?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi On Tuesday 12 October 2010 at 4:05:45 AM, in mid:4cb3d089.3010...@fifthhorseman.net, Daniel Kahn Gillmor wrote: re-entering the passphrase each time is significantly more annoying than confirming its use in a reasonable context. (and re-entering the passphrase every time the secret is used is less secure than a simple confirmation prompt, since it trains the user to type their passphrase over and over again) The user can type their password once per session into a text file and paste it every time it is requested. This reduces the annoyance factor and does not train the user to constantly re-type the passphrase. - -- Best regards MFPAmailto:expires2...@ymail.com Don't talk unless you can improve on the silence -BEGIN PGP SIGNATURE- iQCVAwUBTLY6qKipC46tDG5pAQo3wAP+Ib5WaZw6IGAiLkOCZFCXgZd0NJv2j+Qo 4ipPkPwdl+MjhnQG5iVMyc0IzFpJ5JJmK0y1pgwiSoRvZTh6mFy3U8af/YG+OIvE cu9x4xLw7yaulurvQ8b1r27L2IQIM8/OQQAgN/UapLuLaIzj//ZhRm8GxYA3uZ2J oSPTWL70TLw= =Y292 -END PGP SIGNATURE- ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Confirmation for cached passphrases useful?
On Tue, 12 Oct 2010 04:44, d...@fifthhorseman.net said: (e.g. one process can send a simulated mouseclick to another process pretty easily) but that doesn't mean no one is running with a The standard pinentry grabs mouse and keyboard and thus we should be protected against this kind of attack. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Confirmation for cached passphrases useful?
On 10/12/2010 02:26 AM, Werner Koch wrote: On Tue, 12 Oct 2010 04:44, d...@fifthhorseman.net said: (e.g. one process can send a simulated mouseclick to another process pretty easily) but that doesn't mean no one is running with a The standard pinentry grabs mouse and keyboard and thus we should be protected against this kind of attack. I think that grabbing mouse and kbd prevents other tools from *reading* the kbd and mouse events. It doesn't prevent synthesized events from triggering those inputs (e.g. clicking OK on a button). As a simple example, try: sleep 3 xdotool key Return echo GETPIN xxx | pinentry The backgrounded process hits the enter key on a foregrounded (grabbed) pinentry-gtk. So while it's useful to protect passphrase entry from other snooping X11 applications, i don't think that the kbd/mouse grab approach is sufficient protection for a simple confirmation prompt dialog box. I'd be happy to be corrected on this if i'm wrong, of course. Regards, --dkg signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Confirmation for cached passphrases useful?
Am Dienstag 12 Oktober 2010 06:34:48 schrieb Robert J. Hansen: If my attack gives me unprivileged access I'm going to escalate it to root. going to, yes. This is straight out of the malware playbook, and malware authors have a great many ways to achieve it. I think that it is not useful to equalize unpriviledged and root access. This seems to me a bit ignorant of people trying to get their systems secure. :-) Heck, this doesn't even defend against an *unprivileged* attack. Give me unprivileged access to your user account I'll edit your .profile to put a .malware/ subdirectory on your PATH and drop my trojaned GnuPG in there. There are ways to prevent this. E.g. I protect important and hardly ever changed files like ~/.gnupg/options with root priviledge (chattr immutable on ext3). My most threatened processes (browser, IM) are covered by AppArmor profiles which hevily restrict access to $HOME but not to /tmp. These cannot access the secret keys, of course. But due to the new design of GnuPG 2.1 this may change. This seems like an niche solution to a problem which, as of right now, is nonexistent. As Daniel already pointed out: Few people do but there are possibilities to harden your system. It would seem strange if of all things a security software put a limit to such efforts. Thus gpg should offer improvements even if these do not make much sense ALONE (which should be mentioned in the documentation). Hauke -- PGP: D44C 6A5B 71B0 427C CED3 025C BD7D 6D27 ECCB 5814 signature.asc Description: This is a digitally signed message part. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Confirmation for cached passphrases useful?
Am Dienstag 12 Oktober 2010 09:05:56 schrieb Daniel Kahn Gillmor: I think that grabbing mouse and kbd prevents other tools from *reading* the kbd and mouse events. It doesn't prevent synthesized events from triggering those inputs (e.g. clicking OK on a button). But this may change in the future. On the one hand you are free to have X clients running untrustedly (which should make that impossible) on the other hand I read rumores about the SELinux people heading at changes to their LSM in order to address the (more than obvious...) X problem. Hauke -- PGP: D44C 6A5B 71B0 427C CED3 025C BD7D 6D27 ECCB 5814 signature.asc Description: This is a digitally signed message part. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Confirmation for cached passphrases useful?
On 10/12/2010 1:54 AM, Daniel Kahn Gillmor wrote: yes, of course this isn't going to be able to protect the user from someone with full access to their user account or their current session. These two attack modes (root and user access) cover the overwhelming majority of instances today, so already this hypothetical attack is an exotic. On top of that, your imagined situation seems to involve a compromised machine communicating with a trusted server over a socket. If the trusted server sends back a confirmation request, what's to keep the malware from simply saying, OK, in response to these requests? Conversely, people won't run well-isolated subsystems if the tools we provide don't support reasonable separation and control in the first place. Please do not mistake this for snark. It's not. I'm using an absurd position here to try and make my objections clear, not because I'm trying to denigrate your views. That said: People will also not use GnuPG as a personal flotation device in the event of a water landing if GnuPG does not float. GnuPG is not a personal flotation device and, unsurprisingly, doesn't have any features related to that. This said, if users want GnuPG to offer pontoon functionality in 2.2 they are certainly welcome to make their opinions known. If more than a dozen people say, yes, I need GnuPG to serve as a personal flotation device, I will happily get out of the way and encourage it to be added. But to talk about how the people need personal flotation support in GnuPG, without actually hearing from users who genuinely need it... I might have great respect for the speakers and might even agree with their opinions: but in the absence of user demand, I wouldn't think we should do it. smime.p7s Description: S/MIME Cryptographic Signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Confirmation for cached passphrases useful?
On Tue, 12 Oct 2010 09:05, d...@fifthhorseman.net said: the kbd and mouse events. It doesn't prevent synthesized events from triggering those inputs (e.g. clicking OK on a button). You are right. However it is the only protection we can use on X; it might be helpful in some cases, but as you showed not in this one. Anyway, if you are already have these permissions you can attack the keys with all kind of simple tricks. Thus it is mood. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Confirmation for cached passphrases useful?
On Tue, 12 Oct 2010 11:10, mailinglis...@hauke-laging.de said: There are ways to prevent this. E.g. I protect important and hardly ever changed files like ~/.gnupg/options with root priviledge (chattr immutable on It doesn't help - you need to protect gpg.conf and gpg.conf-2 and gpg.conf-2.0 and so on. BTW, ~/.gnupg/options is deprecated for ages. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Confirmation for cached passphrases useful?
On 10/11/2010 09:25 PM, Hauke Laging wrote: I just had the idea that it might be a good countermeasure against malicious software not to use a cached passphrase without any user interaction (and thus without user notice). A good compromise would be to open a dialog which does not ask for the passphrase but just for the confirmation that it's OK to use the passphrase. The dialog could mention the process accessing gpg-agent. I agree this would be useful, with a few notes: 0) clients that have full access to the X session (or terminal, or whatever mechanism is used for the prompting) can probably auto-accept the prompt. So malicious clients with this access wouldn't actually be prevented from unauthorized access. However, not all clients necessarily have this level of access, so it can still be useful from security perspective. 1) gpg-agent might not be able to determine useful information about requesting processes in some configurations, and on some operating systems. 2) users should be able to specify which passphrases (or secret keys?) they want to trigger a prompt for (some might not need or want a prompt). 3) it would be nice for the prompting facility to be flexible enough to support alternate prompt techniques (possibly differing from the pinentry used to supply passphrases in the first place). For example, it would be nice if a prompt could only be accepted by some physical response from the system (assuming the malicious client doesn't have superuser access, in which case all bets are off anyway), even if the alert for the prompt shows up via the windowing system or the console. --dkg signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Confirmation for cached passphrases useful?
On 10/11/2010 9:25 PM, Hauke Laging wrote: I just had the idea that it might be a good countermeasure against malicious software not to use a cached passphrase without any user interaction (and thus without user notice). The most obvious way I see to circumvent this involves throwing a trampoline on the UI library and bypassing this code entirely. It's a two-hour hack, assuming you already have root access to the system. It might make users *feel* more secure, but it doesn't actually help overall system security -- IMO, at least. YMMV. smime.p7s Description: S/MIME Cryptographic Signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Confirmation for cached passphrases useful?
On 10/11/2010 10:20 PM, Robert J. Hansen wrote: On 10/11/2010 9:25 PM, Hauke Laging wrote: I just had the idea that it might be a good countermeasure against malicious software not to use a cached passphrase without any user interaction (and thus without user notice). The most obvious way I see to circumvent this involves throwing a trampoline on the UI library and bypassing this code entirely. It's a two-hour hack, assuming you already have root access to the system. If you already have root access on the system, then yes -- all bets are off. but that's the case anyway when the malicious attacker has root access. It might make users *feel* more secure, but it doesn't actually help overall system security -- IMO, at least. YMMV. It would help against the situation where the malicious client does *not* have superuser access and cannot directly override the prompting mechanism through other mechanisms. Many standard X11 desktops today don't have such protections in place (e.g. one process can send a simulated mouseclick to another process pretty easily) but that doesn't mean no one is running with a well-isolated gpg-agent. --dkg signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Confirmation for cached passphrases useful?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hauke Laging wrote: Hello, I just had the idea that it might be a good countermeasure against malicious software not to use a cached passphrase without any user interaction (and thus without user notice). A good compromise would be to open a dialog which does not ask for the passphrase but just for the confirmation that it's OK to use the passphrase. The dialog could mention the process accessing gpg-agent. CU Hauke This seems like something that would get really annoying really quickly. Why not just change settings to not cache the passphrase if you do not like using it this way ? -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJMs8A+AAoJEPXCUD/44PWqVHUP/i2jbdt/AsYx2IlrrNqMdtjw 8lnxlUTeOfM11vOHD1CWctJsUH1LyhihKmf+0WZZRSv7k3S1vkVcIPD6zRmee4IS AI+3wvtlGdsF/+BlMeelCMMdaU8ys4OB4YbfQdaftAsBsO3IqZ32K1VLkMcje6Wd YdREF/dDEzD41tJ/oQLwxW8Ek9IBTUDrA7p1HdCuzf5YfqdDF0eLvTaGXCK6mO7e RJeSLlelQs7kgTq1KEvOAMGgpF8vye8soLN3aJcxkZnjp991Eeus6ZIhxdYRoXIz o7sPTf8ejctUrgGrW00hVUoUMhCdKN+ELx4Ux0fIgDGzMVItYRDXrAnbTeuZ2z3x /3gBAQbAQWWvFXQZ6CQT3uNJQVtOmTwber8DjSaSRsRxNsQbh15SeOIHEGgI73wk xEfvoL7iirMOcVmjndGc6063nUPvhJyotvefafrOKbL3vae7C8480x1kc0uhB2Ry U9daKonVyCPGyqAhqem1oYpPjjD2aUuyDzLM4y7t0yfKAwEqjL+vQogGfilyKYhy U+g/OybkgQLckG5RgnEcqzlIcSWPdnl6eIxc/YF8EMxYpcXrZhXMrGkk8fDVC36R 3TM/siVhttdo7v9ekFxT3eOF/6vsKoASpP1Vz4aZXpSQ8a3/WRW5eDyQ6li4goKH Ub+vZOmMc14HvzSAlBpt =+JVD -END PGP SIGNATURE- ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Confirmation for cached passphrases useful?
On 10/11/2010 09:56 PM, Larry Brower wrote: This seems like something that would get really annoying really quickly. Why not just change settings to not cache the passphrase if you do not like using it this way ? re-entering the passphrase each time is significantly more annoying than confirming its use in a reasonable context. (and re-entering the passphrase every time the secret is used is less secure than a simple confirmation prompt, since it trains the user to type their passphrase over and over again) --dkg signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Confirmation for cached passphrases useful?
On 10/11/2010 10:44 PM, Daniel Kahn Gillmor wrote: It would help against the situation where the malicious client does *not* have superuser access and cannot directly override the prompting mechanism through other mechanisms. This attack mode appears to me to be so niche that I don't see any point in defending against it. If my attack gives me local access I'm going to shoot for remote. If my attack gives me unprivileged access I'm going to escalate it to root. This is straight out of the malware playbook, and malware authors have a great many ways to achieve it. Heck, this doesn't even defend against an *unprivileged* attack. Give me unprivileged access to your user account I'll edit your .profile to put a .malware/ subdirectory on your PATH and drop my trojaned GnuPG in there. Once the malware executes, delete the hidden subdirectory, restore your original PATH, and send the passphrase it intercepted off towards my C4I server. And if we're assuming I've instead subverted an unprivileged non-user account (like a jailed service), then this attack is a nonissue, so why are we trying to solve it? This seems like an niche solution to a problem which, as of right now, is nonexistent. smime.p7s Description: S/MIME Cryptographic Signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Confirmation for cached passphrases useful?
On 10/12/2010 12:34 AM, Robert J. Hansen wrote: Heck, this doesn't even defend against an *unprivileged* attack. Give me unprivileged access to your user account I'll edit your .profile to put a .malware/ subdirectory on your PATH and drop my trojaned GnuPG in there. Once the malware executes, delete the hidden subdirectory, restore your original PATH, and send the passphrase it intercepted off towards my C4I server. yes, of course this isn't going to be able to protect the user from someone with full access to their user account or their current session. Agents like gnupg-agent and other socket-driven services are capable of being exported over heavily-constrained connections, where only access to the agent's socket is given to the attacker. For example, you can forward ssh-agent over the network to a process on a remote host, or set up a simple socket-forwarding service within a machine to grant access to your gnupg-agent to other user accounts. As an example, I know people who run their web browser in a heavily-constrained mode, e.g. under a separate user account, in a virtual machine or VNC session. If such a browser (or a plugin to it) wants access to the principal user's agent, it has only one recourse, which is to talk to the agent's socket. (This sort of constraint is much more effective with the ssh-agent model, where secret key material never leaves the agent, as opposed to the traditional gpg-agent model where the agent is only a passphrase cache; it sounds like gpg-agent is planning to adopt the ssh-agent model as of 2.1, which is great news.) And if we're assuming I've instead subverted an unprivileged non-user account (like a jailed service), then this attack is a nonissue, so why are we trying to solve it? If the specialized/jailed account has access to such a forwarded agent, then an attack against it *is* an issue. It would be good to be able to grant gpg-agent access to the constrained service when it requests it reasonably, and to be able to deny it when it requests access unreasonably. This seems like an niche solution to a problem which, as of right now, is nonexistent. Conversely, people won't run well-isolated subsystems if the tools we provide don't support reasonable separation and control in the first place. Do we want to build tools that support secure use? If so, implementing Hauke's suggestion at least in the GPG 2.1 branch is a good idea. And previous branches would be nice too, though the classic gpg-agent communication model (passphrase-cache-only) is too weak for the proposed confirmation prompt to enable well-isolated use. --dkg signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
