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:
- Protecting from phishing John LaPrad (Oct 19)
- <Possible follow-ups>
- Re: Protecting from phishing Joel Rosenblatt (Oct 19)
- Re: Protecting from phishing Paul Kendall (Oct 19)
- Re: Protecting from phishing Flynn, Gerald (Oct 19)
- Re: Protecting from phishing Jesse Thompson (Oct 19)
- Re: Protecting from phishing Leo Song (Oct 20)
- Re: Protecting from phishing Valdis Kletnieks (Oct 20)
- Re: Protecting from phishing Valdis Kletnieks (Oct 20)
- Re: Protecting from phishing John LaPrad (Oct 20)