We primarily focused on vulnerabilities that should be obvious to a careful visitor to a web site by simply examining the site's contents and its rendering in a browser. Some of the vulnerabilities we examined could make it difficult for a customer to know if they are seeing content provided by the bank or by an attacker.

An example of a common design flaw is providing a login window on an insecure web page. Most banks have code behind the web page that submits the login information securely, but there is no obvious way for a customer to know that by examining the URL or the page's rendering in a browser. We found that we could mirror such a bank's web site fairly easily and, if the user is on insecure network, mount an attack that would capture a user's id and password without the browser or the user being able to distinguish the real site from the mirrored site.

Users can be on insecure networks frequently, and arguably all the time. If you are connecting to the Internet from an Internet cafe or from a hotel, you have no way of knowing if you are on a secure network. Note that the Internet is usually considered insecure. So, in principle, your traffic could be eavesdropped or modified even when you are browsing from your home or work. Of course, the opportunity for an attacker to eavesdrop or may be higher at an Internet Cafe or a hotel.

It is also well known that vulnerabilities in the DNS (Domain-Name Service) can also cause you to visit a spoofed page without affecting the URL displayed in the browser. Such a problem came to light recently. If your DNS server is compromised, you could be vulnerable almost anywhere.

To start with, all their web pages should be available *only* on secure sessions. As a user, you can tell whether a page is on a secure session by observing if the URL starts with "https://your-bank-web-site/".

Many banks also redirect a user to a third-party site for some services, such as authentication. When that happens, the new site should be be properly introduced (from a secure page owned by the bank) so that the user is made aware that they are visiting a trusted third-party site. Without that, there is a potential for user confusion. Banks are effectively sending a wrong message to a user that the domain name in the URL does not matter.

Banks probably use third-party sites for some services because other companies are better able to provide some services. We should remember that many banks are small and may not have the resources to handle all their IT services. But, there are possible solutions that would help address our concerns and not require changes to that business model entirely. For example, a bank could use hostnames such as secure.bankname.com, which is still in the same domain as the home page, but have that host's services be provided by a trusted entity.

(Note: Unfortunately, bugs in Domain Name Service, which translates hostnames to IP addresses could theoretically extend the reach of the attackers to allow remote attacks. On July 11th, CERT issued an advisory for a massive multivendor patch to DNS. As per the advisory, any unpatched Name Server could be potentially compromised)

We do recommend you review your bank's web site carefully in light of the study so that you are aware of its security flaws. If you find flaws, use the site carefully to minimize the risks. The most basic flaw is your bank serving you content on a non-HTTPS page. You can tell that by examining the URL in your browser. The URL should start with https://your-bank-web-site/... If you do not see that, then you need to avoid connecting to the bank from networks that you do not control or completely trust.

If your bank provides a login window on an insecure page, sometimes you can just hit the Submit button and land on a secure page. If that happens with your bank, we suggest doing that. Make sure you examine the URL to make sure you are still on your bank's site. (Unfortunately, many banks will take you to a different domain for login and it can be hard to tell whether that new domain is still part of your bank).

As authors, we continue to maintain accounts at some of the banks that may have these flaws because of the conveniences or other benefits banks provide, but we educated ourselves about safe web site usage and are aware of the risks. To minimize the risks, we recommend against using the sites, unless essential, when on an unknown network, unless the web site follows the guidelines in our study. The risks could be higher in that case.

We decided to do this study partially because we saw these problems at the sites we banked at and saw that the problems were not unique to our own banks.

Please see the paper for the key limitations (end of Section 5). In some cases, they may make the numbers we report conservative. For example, failure to download all pages may cause us to miss flaws that actually exist.

Also note that not all flaws are equally serious. We consider the lack of use of SSL on the login page as the most serious issue, as there could be exploits (even remote ones) that could steal userid/password, as shown in our video presented at our talk for a current site.

Banks can start addressing our concerns by using a single domain name for the entire site and protecting all the pages using SSL (https). Customers then may have a better shot at telling apart spoofed or fake pages from real pages.

No. We chose to not make individual site results public at this time. It is not clear if that will serve a positive purpose. We already give a few examples of specific sites to simply illustrate the points in the paper. Furthermore, we may have missed flaws that exist (see Limitations above), so listing a site as not having flaws would not necessarily imply that it lacks the flaws. In most cases, customers need to educate themselves and do their own due diligence on their banks or financial institutions to see the extent to which they have problems.

In the end, our work will hopefully lead to more consistent and simpler financial web sites: those that stick to a single domain preferably, consistently use SSL for all interactions with customers, and adapt clearly stated policies. Hopefully, then customers will have a better shot at identifying content that they should not trust when they attempt to visit financial sites.