Educause Security Discussion mailing list archives

Re: Protecting from phishing


From: "Flynn, Gerald" <flynngn () JMU EDU>
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

Current thread: