Endpoint Protection

 View Only

On Bank-Specific Top-Level Domains 

Jun 01, 2007 03:00 AM

Recently, Mikko Hypponen proposed the idea of a .bank top-level domain extension as a way to combat phishing attacks (see 21 Solutions to Save the World: Masters of Their Domain). The proposal garnered some significant interest including two Slashdot threads: A Foolproof Way To End Bank Account Phishing? and F-Secure Responds To Criticism of .bank.Since phishing is a topic that I spend a considerable amount of timethinking about, I thought I’d spend some time considering the benefitsand drawbacks of Mikko’s proposal.

First, let me summarize my understanding of the proposal. The ideawould be to have a top-level domain along the lines of .bank (inaddition to top-level domains like .com, .net, .gov, etc.). Further,only legitimate institutions should be allowed to use the .bank domain.Ownership of sites on this domain can be further restricted by charginga sizeable fee (for example $50,000 a year) to anyone who wishes tooperate such a site. These restrictions should keep illegitimate peoplefrom operating a site on such a domain. So, the argument goes thatanytime you see a site on the .bank domain, you can trust it.

Now let’s consider the challenges:

  • Phishers don’t have to use the .bank extension and most users willfail to notice. For example, instead of using www.phishing-site.bank,they could use www.phishing-site.com or evenwww.phishing-site.bank.xskfkfjfs.com.). Users have a hard enough timenoticing traditional security indicators like padlocks in browserwindows; they are hardly likely to notice that the URL in strange. Infact, if you look at almost every phishing site these days, the URLitself is a blatant giveaway that you’re not at an authentic site.Phishers have realized that they usually don’t have to resort tocomplicated tactics to fool their victims.
  • Not all phishing involves banks. In the last sevenmonths of 2006, Symantec found that roughly 36.5% of phishing sites didnot involve financial institutions. Also, not every phish site in thefinancial sector actually involves an official bank.
  • For this proposal to work, one would have to agree onan official definition of a bank. Agreeing on a definition that islegally binding seems like no easy feat. The complexity is furthercompounded when you consider that different countries might havedifferent criteria. Who gets to decide the official criteria? Even ifyou finally agree upon them, I can imagine that there might bechallenges in enforcing these criteria (and also in deciding who canenforce them in the first place). These challenges may not beinsurmountable, but they almost certainly have to be considered.
  • Credit unions and smaller banks might get shafted since50k will mean more to them,so they will be less able to afford suchsolutions. Of the 343 brands we saw being spoofed in phishing attacksfrom Jun through Dec 2006, 122 corresponded to smaller US banks thatconducted business in five or fewer US states. Of these, 89 conductedbusiness in only one US state. Just because these institutions aresmall, doesn’t mean that they aren’t targeted.
  • The proposal will also lull users into a false sense of security for a number of reasons:

    1. The bad guys may still be able to get .bank domains. From theevidence we’ve gathered at Symantec, many phishing sites are operatedby organized criminal elements. Coming up with the requisite dollaramount to purchase a .bank domain is not a barrier. It may be trickyfor them to prove that they are a bank to a domain registrar, but it isnot outside the realm of possibility.
    2. The proposed solution won’t stop phishing attacks thatexploit cross-site scripting vulnerabilities. If the cross-sitescripting vulnerability occurs in a site that is hosted on a .bankdomain, that could be especially problematic. (See my previous blogentry Phishing and Cross-Site Scripting).Similarly, users aren’t protected against pharming attacks where adomain with a .bank extension is directed to an IP address that theattacker owns.
    3. Browsers are sometimes susceptible to address-baroverlay vulnerabilities. In such cases, the phisher can put a graphicimage over the browser’s actual address bar. Users may fail to realizethat the real-looking web address displayed on the graphic differs fromthe site’s actual address hidden beneath the graphic.


To provide a more balanced view, let me discuss a couple of potential benefits of the proposal:

  • Banks may find that employing such a strategy is sound from arisk-management perspective. For example, suppose that anytime aphishing attack ensnares a victim, it costs the bank $5,000.00 USD onaverage. If using a .bank extension prevents more than ten of thebank’s customers from being victims throughout the course of a year,then it pays for itself. One can see that there is a pretty clearalignment of economic interests. This benefit alone may be enough towarrant considering the proposal (assuming you can get past somedetails like being able to agree upon what a bank is).
  • A .bank extension might be a helpful aid toanti-phishing toolbars when they determine the legitimacy of a site. Ofcourse this potential benefit has to be weighed against the risk ofluring users into a false sense of security, as described above. I’dpersonally prefer a more restricted approach of white-listing specificsites rather than an entire top-level domain.
It’s not clear whether this proposal will ever be implemented, but Ican imagine that either way it will generate a considerable amount ofdiscussion.

Statistics
0 Favorited
0 Views
0 Files
0 Shares
0 Downloads

Tags and Keywords

Related Entries and Links

No Related Resource entered.