Phishing is a very serious problem that we face. However, banks are the biggest targets. What methods can a bank use to protect its self from phishing attacks? What methods should someone use to protect themselves. Why does it stop attacks?
+2
A:
Use an EV SSL certificate, and then put a message on your login pages that tells users to look for the EV Signature in their browser.
Make it clear in your emails that your bank will never ask a user for their password. Setup a special email dedicated to phishing so customers can send you suspected emails, and you can then notify customers.
webdestroya
2010-06-20 20:53:50
This is already what's done. Users don't typically notice the bar or _care_.
Longpoke
2010-06-20 20:56:35
This is a general problem with users. They never care. They only start caring when shit hits the fan, and then it's your fault.
LukeN
2010-06-20 20:59:06
I once saw a nice research where they used the familiar lock icon as *favicon* to their site and that alone tricked enough users into thinking it was genuine.
Joey
2010-06-20 21:15:43
@Johannes - That doesn't happen with an EV SSL - The whole address bar will turn green, and not just put the lock.
webdestroya
2010-06-20 21:39:07
@webdestroya Does IE6 do that? IE7? IE8? Firefox? Chromium? Safari? Some browsers don't show any notification about it.
LukeN
2010-06-20 21:54:43
@web: That doesn't help if the *user* thinks it's secure from the lock icon alone. You know, those things are about social engineering, not about actually *breaking* security protocols.
Joey
2010-06-20 22:16:25
@LukeN - No, Yes, Yes, Yes, Yes, Yes, Yes. (most do show it)
webdestroya
2010-06-21 01:26:02
Firefox, Chrome, IE: they've all changed or improved the UI, making a site's secure/trusted status more visible. Eventually insecure, untrusted sites might get more of an ominous look. In other words, go with this answer. Use a secure (`https`) site, with an enhanced certificate. The browser's will help convey that to your users.
Ian Boyd
2010-06-21 17:09:02
+3
A:
IMO, the best thing that a bank can do is to educate it's users on when and how they will communicate with them. Many users have no idea about what phishing is and so showing them examples and raising their awareness about fraud will do more than any technical solution (though the technical side should be pursued just as aggressively). A user aware that phishing can occur will be far less likely to fall prey to it.
VirtuosiMedia
2010-06-20 20:56:39
Unfortunately, the more aware users are of security risks and the fact you are trying to fight them, the MORE likely they will be to fall prey to other social engineering, such as an e-mail saying "To help keep your online banking experience secure, we're providing all of our customers with a complementary copy of *whatever* anti-virus suite." The installer, of course, isn't a genuine security tool but a keylogger.
Ben Voigt
2010-06-20 21:09:23
@Ben - I'm not so sure. I guess it depends on how you do it. I would say: We will only email you for the following reasons: A, B, C, etc. Any other emails aren't from us and should be treated with suspicion. Also, here are ways you can identify phishing emails: Wrong URL or email, spelling errors, poor or slightly-off graphics, requests for password, suspicious requests, etc.
VirtuosiMedia
2010-06-20 21:23:59
Teaching them to think critically would help alleviate that concern, i.e., *why would my bank ask me to install an anti-virus software?*
VirtuosiMedia
2010-06-20 21:25:10
@VM: What user is actually going to consult the list of reasons the bank might e-mail them? I won't even get into the difficult of teaching critical thinking to the typical phishing victim, but why don't you apply your critical thinking skills. Start with the premise that (1) for some types of accounts (e.g. credit cards in the USA), the bank bears the financial loss due to unauthorized use, and (2) in large volumes, digital distribution of software is extremely inexpensive. It's possible some banks might decide there is financial advantage in buying antivirus software for their users.
Ben Voigt
2010-06-20 21:45:03
Sure, it's possible that banks could do that. I don't know if it's likely, but it's possible. My point, however, was simply that in addition to all of the technical measures, which are necessary and vital, it is good practice for banks and other payment processors to educate their users on online security. Case in point, PayPal: https://www.paypal.com/fightphishing
VirtuosiMedia
2010-06-21 03:03:27
+5
A:
Phishing usually works by directing the consumer to a scraped version of the website. One method that's starting to be more common is a dynamic website, where after entry of username and before entry of password, the bank site reveals some image or phrase chosen by the consumer, which I will call the counter-password. In essence, not only must the consumer present a valid password, so does the bank. Mutual authentication.
The phishing site cannot display the correct counter-passwordwithout querying the bank, and this gives the bank an opportunity to detect, confound, and prosecute the proxy.
This can be enhanced with use of an out-of-band communication channel. If the IP address making the request (which would be the proxy, possibly via onion routing) isn't one the consumer has logged in from before, send the consumer an SMS with a one-time code they must additionally use before the counter-password is revealed and login enabled.
Other methods are for the browser to cache the correct server certificate and tell the consumer when they visit a site without a cached certificate, thus warning the consumer that this isn't the familiar site they've used before.
Ben Voigt
2010-06-20 20:56:42
I doubt that this would work. You say that the bank would be able to detect the proxy. Such a proxy may be using a different IP for each request, be using a bot-net or whatever technology it needs to stay anonymous. You could then run a real-time man-in-the middle attack circumventing the counter-password security. Of course, this is more advanced stuff than simply stealing passwords from fake sites.
0xA3
2010-06-20 22:13:18
+1 for mutual authentication and cached certificates, but using SMS **must** be an optional measure since it fucks usability. (That applies to most out-of-band security measures actually.)
David X
2010-06-20 22:19:00
@A3: That anonymity is what I meant by onion routing. Here's where the SMS or phone call comes in. The bank can easily figure out the IP address (or 2 or 3) the consumer uses most frequently. The bot-net won't be among them, and that's enough of a warning sign to justify contacting the customer on their cell phone, either voice or SMS, and also NOT show the counter-password. Since the SMS will also explain "Here is the code you need to access your account from a computer you've never used before" the customer should be clued in as well.
Ben Voigt
2010-06-20 22:24:34
@David: Give the user the choice between SMS and automatic voice response. Plus, it's only activated when the customer's IP address changes (throw in a browser cookie check too, for good measure, to alleviate customer home computers on dynamic addressing), so the diminished usability really isn't much of a problem. After all, the goal of encryption is to make the good guy do something moderately difficult, and make the bad guy do that same moderately difficult thing a few trillion times.
Ben Voigt
2010-06-20 22:29:39
@Ben Voigt, the problem I see isn't SMS per se, but rather what happens when the user doesn't have a cell phone. Your site shouldn't depend on the availability of a largely unrelated system.
David X
2010-06-20 22:38:13
@David: You can have a voice alternative to SMS that calls any phone defined in the user's profile, cell or not, and reads a one-time PIN. Using a "largely unrelated system" is kind of the point, as it's unlikely for both to be compromised at the same time by the same criminals.
Ben Voigt
2010-06-21 03:04:49
It would be better to make the mutual authentication *strong* using certificates than checking for the user's IP and using SMS. However, this comes with higher cost as users need to be equipped with a security token or smart card.
0xA3
2010-06-21 08:36:55
@Ben, my point is that it shouldnt require it; by all means, make this feature available, but *forcing* users to use it is worse than not having it at all.
David X
2010-06-21 09:22:29
@A3: Server certificate checking is great, but requires (1) help from the browser and (2) an out-of-band mechanism for verifying the identity the first time the certificate is transferred. Security token/smartcard, SMS, voice confirmation, are all methods for securing the first-time setup of a client computer. In addition, IP checks hinder attackers from using stolen credentials, but mutual certificate authentication doesn't. So you want to use them in concert.
Ben Voigt
2010-06-21 14:35:52
@David: As long as it's optional on a per-account basis, not a per-session basis. If the user has configured SMS-based authentication, you're going to force them to use it whenever any anomaly (like IP address change, no cookie, etc) is detected. It sure is a lot more convenient for most users than giving bit-perfect answers to 5 security questions.
Ben Voigt
2010-06-21 14:40:54
@Ben, very true, I'd assume per-account went without saying. Also, do *not* use 'security' questions; thats what passwords are for.
David X
2010-06-22 02:11:01
+1
A:
The best way to prevent phishing attacks should rely on technical means that don't require the user to understand the problem. The target audience will always be large enough to find someone who gets fooled.
A good way to prevent from attacks is to use an authentication mechanism that doesn't rely on a simple pass phrase or transaction authentication number (TAN) that an attacker can steal.
Existing methods e.g. use dynamic TANs (Indexed TAN or iTAN), or a TAN submitted on a separate channel via SMS (mobile TAN or mTAN), or - most secure and also preventing from real-time man-in-the-middle attacks - require the user to sign each transaction, e.g. using DigiPass or a smartcard.
The reason that this is not widely implemented is probably that it is still more cost-effective for banks to pay for the damage from phishing attacks than investing in security.
0xA3
2010-06-20 21:14:40
+1
A:
The easiest way to mitigate it from a bank perspective would be to educate customers upon account creation that (a) the bank does not have the customer's e-mail address, so it simply can't send mails to them and (b) send a letter to every existing customer once, explaining the same.
For the customer this has the benefit that they will know that whenever they receive a mail claiming to come from their bank it can't be real.
Joey
2010-06-20 21:14:56
Unfortunately banks do have the customer's e-mail address, so they can (and do) send legitimate e-mails to you.
ChrisF
2010-06-20 21:46:45
I, for one, happen to like online banking. So my bank has my e-mail address and is expected to use it. There's only been one occasion where I couldn't immediately determine if an e-mail was legit (one of the "to continue using your account you need to login and fill out this form", but other than that warning sign it was perfect w/correct legal name, good URLs, etc.) I closed my browser, called the bank using the number saved in my phone (not the one in the e-mail), and after determining they actually did send that message asked the rep to pass on my extremely negative feedback.
Ben Voigt
2010-06-20 21:50:29
My bank does *not* have my e-mail address and I intend to keep it that way. Online banking around here is not tied to an e-mail address either. However, I was quite surprised when another bank upon opening of an account *demanded* to know my e-mail address (they sent mostly spam them, from my perspective). They still did all important things via snail mail so the e-mail address seemed to be exclusively for advertising – yet still mandatory.
Joey
2010-06-20 22:08:39
+1
A:
I recommend analyzing online banking fraud based on the types of attacks: stolen credentials, Man-in-the-middle and malware/man-in-the-browser and how authentication can thwart them: two-factor authentication for sessions, mutual authentication to prevent MITM and transaction authentication for MitB. I wrote an article about this in 2006: http://www.bankinfosecurity.com/articles.php?art_id=115&pg=1 and I wrote a doc tutorial on mutual https authentication: http://www.howtoforge.com/prevent_phishing_with_mutual_authentication. EV certs are little additional value for many of the same reasons that standard ssl of little value: no one knows how to validate a certificate and the UI cannot be trusted. Using images is of no valued and makes for a really annoying user experience.
While SMS is better than static passwords, you are then relying on the security of the cell carriers. However, since they have so many users and increasing the security of their systems means more helpdesk calls, incentives are not aligned. Also, please reference the latest snafu with the iPad email addresses where even basic security principles were not followed.
Banks need to get serious about designing systems and/or using vendors that base their architecture on solid security principals and follow standard encryption techniques rather than marketecture with an eye towards meeting miniumum compliance standards.
nowen
2010-06-21 16:43:23