Re: Protecting from phishing

[Leo Song <song () UOGUELPH CA>]

I am skeptical about this approach, but surely I would follow this
thread to see how it goes, the Internet is built based on the trust, but
adversely we often become victims of such trust, I am hoping something
could be done at network routing part, maybe BGP could have another
field called "reputation", as of today, besides of user education
program, the "best" approach would be having a firm procedure to react
phisher's actions.

Leo

-----Original Message-----
From: Flynn, Gerald <flynngn () JMU EDU>
Reply-to: The EDUCAUSE Security Constituent Group Listserv
<SECURITY () LISTSERV EDUCAUSE EDU>
To: SECURITY () LISTSERV EDUCAUSE EDU
Subject: Re: [SECURITY] Protecting from phishing
Date: Mon, 19 Oct 2009 15:08:47 -0400

> -----Original Message-----
> From: The EDUCAUSE Security Constituent Group Listserv
> [mailto:SECURITY () LISTSERV EDUCAUSE EDU] On Behalf Of John LaPrad
> Sent: Monday, October 19, 2009 2:13 PM
> To: SECURITY () LISTSERV EDUCAUSE EDU
> Subject: [SECURITY] Protecting from phishing
>
> We have had multiple users, faculty and students fall for phishing
> exploits in the past few months. We have an education program, we block
> spam (some still slips through), we wrote custom filters to make sure
> no one replies to phishing emails (they started embedding links to
> websites instead) and these phishing attempts are still working
> occasionally.
> I was wondering if it would be reasonable to front the email servers
> with a system, like some banks do, where the system remembers your IP
> and whenever you connect from a new IP, you have to take some
> additional step before getting in.
> I think that this would stop the phishers.
> Is anyone doing something like this, or heard of it?
> Maybe I am missing something, and this simply would not work?
> I appreciate any feedback.

That might work if the phishers were connecting only to your web
interface with compromised accounts to send the messages.

This is referred to in some circles as an aspect of
risk based authentication or adaptive access control. It
is in many commercial identity management products now.

We're not currently using it but I'm very interested in it.
Factors other than IP addresses can be used. For example,
browser cookies. Or geographic location or ISP rather than
exact IP address match. Or time of day.

Most systems require answers to challenge questions if the
system sees something that policy says needs extra
authentication. Those challenge questions pose the usual
challenges to usability and support.

And all such systems I'm aware of are web based which means
it won't help with phishing messages sent through IMAP, POP,
or SMTP sessions.

For SMTP, greylisting comes close to providing what you describe
but its easily bypassed. The banks have an advantage in that
they are dealing with a known user base and they are interacting
with people. Mail servers, by definition, have to accept
connections from anyone eventually and they are interacting
with machines. Kind of hard to send a challenge question
to an interim SMTP server. :) Well, I guess you could send a
special non-delivery message back to the end user who would
be required to login somewhere and answer some challenge
questions but the delay in user notification would be
unacceptable. SMTP is a store and forward protocol, not an
end to end protocol.

Likewise, IMAP and POP sessions would be difficult without
modifications in the clients. Might be able to do something
with IMAP messaging though. Unlike the SMTP sessions, at least
you have a human being at the other end to interact with.


Gary Flynn
Security Engineer
James Madison University