[cap-talk] RE: [e-lang] Eyes on the goal: real phishing solutions

[Ian G]

David Hopwood wrote:

> David Wagner wrote:
>
>> marcs writes:
>>
>>> -- Pet Names Everywhere: Full fledged pet naming systems, built on
>>> unforgeable ids. Graphical pet logos as appropriate. Not just in the
>>> browser, but in the mail tool, the chat tool, the desktop, 
>>> everything. We do
>>> pet names as best we can, which is not a complete solution in itself 
>>> for
>>> reasons described by others in this discussion, observing that 
>>> humans just
>>> don't pay attention that reliably. But phishing is harder. Phishing 
>>> via the
>>> email tool, for example, has to pass the hurdle of coming from an 
>>> unknown
>>> source, in addition to sending you to a web site that is an unknown
>>> destination.
>>
>>
>> I suspect this would help a lot.
>>
>> I think you have also done a good job of capturing part of what makes
>> this hard.  There are several popular channels (web, email, chat) 
>> through
>> which spoofing can occur, and a broad diversity of clients for each 
>> channel
>> (Outlook, Firefox, Pine, Eudora, mh, elm, etc.).  To fix the phishing
>> problem, we have to fix them all, or at least come reasonably close.
>
>
> To allow any particular user to protect themselves from spoofing [note
> careful wording],


Thanks!


> we have to fix all, and only, the channels and software
> used by that user. Example: since I don't use IRC to any significant 
> extent,
> changing either the IRC protocol or any IRC clients to use petnames is
> irrelevant to protecting me from spoofing.
>
> Does anyone think that preventing spoofing for all users over all 
> possible
> channels, and for every client supporting each channel, is a realistic 
> goal?


Nope, not me.  I do not think there is any hope
in fixing any channel.  In a general sense, phishing
is a fraud in a class of frauds that includes invoice
fraud, phone fraud, insurance fraud and basic
stupidity.  There are no shortage of channels
with which to deliver a fraudulent request for
info or money.

OTOH, there are only a few ways that money or
info will be returned in a "trusted" sense.  On the
net, email is almost never used in this context,
unless the user has already established some
sort of interaction, like she's talking to her bank
directly, and she's done a few exchanges.

But, there is one place where she is vulnerable,
and that is the HTML FORM.  There, she sees
this displayed set of boxes and has this irresistable
urge to reveal her every detail.  Which of course
she will do because she was trained to do that,
and it's safe, as long as she checks ... something,
well, it'll be safe...

So, my *personal* strategy is that the protection
should be oriented towards the FORM.  Which
leads one to issues like what is that page, who
is it talking to, etc etc.

Hence, eventually, to the cert.  Recognising that
this is a bit tricky because the users aren't checking
the padlock, and even if they were, it's easy enough
(c.f., Shmoo) to fake that bit.  Also recognising the
alternate that might be made if crypto-enabled URLs
were in place...

iang

-- 
News and views on what matters in finance+crypto:
        http://financialcryptography.com/