"phishing" (was: [patch] Automatically add keys to agent)

[Hank Leininger]

[ Sorry, I did not see the renamed thread until I'd already replied on
  the old one.  Calling this a phishing attack is exactly right. ]

On 2010-01-30, Joachim Schipper wrote:

> If I understand you correctly, you argue that connecting to malicious
> hosts is currently secure, and will remain secure, but that it will
> become easier to convince people to send the passphrase for their key.

Yes.  Exactly.

[ ObDisclaimer: not "is currently secure" but "is currently secure as
  far as we know" ;) ]

> You are right that this is a concern, but note that an attacker would
> only learn the passphrase to a key, which should be uninteresting
> without the key.

Absolutely.  So it's not a complete compromise of usable credentials.
...Unless the user has reused that passphrase somewhere else, and/or
used a "really good password" as also their passphrase.  The attacker
would have to find some other device on which you've used those
credentials, or gain access to your encrypted private key file some
other way.  (Depending on the environment this may not be as difficult
as it should be, such as internal networks using NFS'ed home
directories, etc.  But that is not ssh's fault.)

> More importantly, as you note, the current situation is no better. If
> you currently use keys, the attacker could send another 'Enter
> passphrase for <keyfile>' message to obtain the passphrase. (And of
> course, if you currently use passwords, an attacker could obtain your
> password!)

> You are not wrong, but isn't this point applicable to a much wider
> range of cases than those covered by my patch? And do you know why it
> hasn't been addressed yet?

Agreed.  Really this has always been an issue--people may debate over
how large or small, but it has always been there.  I do not know that it
has been discussed specifically, but it's akin to fake login prompts in
computer labs / internet cafe's, fake "Good signature" PGP output in the
top of an email (when using a text reader like pine and pgp4pine, where
there's no clear delineation between filter-added-headers and message
body), etc.

So, I'm not saying the proposed patch introduces a new technical
vulnerability.  What it (may) do is change people's behavior /
expectations, making the social / phishing vulnerability larger than it
was before.

There is probably room for an entirely different discussion of: can the
ssh(1) client do anything to reduce the risk of this?  Such as
canary'ing the prompts, in a way easy for the user to verify, but hard
for a remote system to blindly guess?  I don't have any good ideas that
seem clean enough to not be highly annoying (or have untenable
requirements like "there must be an X display that ssh can talk to, to
pop the request up in"), but strong enough not to be faked out.  ...If
that were sufficiently addressed, then this downside to AddKeyToAgent
would go away too.

Thanks,

-- 

Hank Leininger <hlein at korelogic.com>
BE5D FCCA 673B D18B 98A9  3175 896E 3D4A 1B4D C5AC
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 443 bytes
Desc: not available
URL: <http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20100201/dcacfd06/attachment-0001.bin>