For videos below, we suggest right-clicking on the video and saving it, and then viewing it locally using a Quicktime Viewer on a desktop display with
sufficient resolution to see the entire video. On my laptop, the top part of
the videos is cut off when viewing it in Safari since they are approximately
720p videos and my browser window was smaller. Thus, the URL was cut off in
some videos, which is critical to the demo. In retrospect, we should have
shot lower resolution videos.
- PDF copy of the our presentation (after minor edits for clarity) on July 25th, 2008 at the Symposium on Usable Security and Privacy.
-
- Quicktime video (warning: large file, non-streaming at this time) illustrating the potential for an attack that spoofs a bank's web site, while the URL is the same on the login page.
Note: The bank's real site was not modified during this demo. Test
user was simply redirected to a different
IP address by supplying an incorrect DNS
mapping to the victim. The IP address hosted a mirror under the simulated
attacker's control. These videos were made in our lab to illustrate the
feasibility of attacks; no cafes were attacked or involved.
Different techniques for carrying out such an attack are well known
in the security and hacker community and we omit a detailed discussion
here.
Some sites that do not appear to have the above flaw (since we are often asked for examples): wellsfargo.com, nationalcity.com, fidelity.com. They all take you to https
pages that clearly belong to the financial institution.
- Quicktime video (large file, non-streaming)
illustrating the potential for an attack that spoofs the bank's "contact us" (customer service) page. Same attack vectors as with the previous video.
Some sites that do not appear to have the above flaw (since we are often asked for examples): wellsfargo.com and nationalcity.com. They all take you to https
"Contact Us" pages that clearly belong to the financial institution.
- Quicktime video (large file, non-streaming) illustrating the problem with the use of third-party domains for parts of a web site
A few examples of banks that do not appear to have the above flaws in the parts of the sites that we checked (since we are often asked for examples):
wellsfargo.com and nationalcity.com. For example, they take you to https pages that clearly belong to the financial institution even after hitting the Login button(s).
- Quicktime video (not-streaming) illustrating normal use of a bank site that uses insecure pages, as of July 2008.
(as a point of reference - we did not show it at the symposium) This bank has since corrected the problem.
Some points to remember about the videos
- For the videos and examples in the paper, we picked on institutions that we really like,
except that we think there is scope for improvement in the design of these institution's web sites with
respect to security. The videos and examples include institutions with
local presence in our town, where we have accounts, and we continue to trust
them with our money. These videos are only intended to serve as examples
to explain the issues clearly so that all banks can benefit and judge if they need to address
our concerns. We have attempted to contact the institutions used in our examples in advance at their
customer service or at higher levels (when we could easily locate the contact information).
We will help them address the issues, as requested.
- Chase.com, which we used as an example in the video, has since corrected the flaw of putting their login box on an
insecure box (as of 1st week of August, 2008). Now a user is redirected
to an https page when attempting to go to http://www.chase.com. Quick response Chase on at least the most critical problem! We hope that other banks will examine their
sites and, if vulnerable, follow Chase's example in quickly correcting the flaw(s).
- An actual attack on a particular customer is likely to be rare (at least, we hope that). But, if it happens, it can
be pretty serious and could be hard to detect (see
this blog entry for more
in-depth technical discussion on this). Vulnerabilities in the Domain Name Service
potentially could allow even remote exploits
of insecure-page vulnerabilities. There is an extremely serious attack code for DNS that was
out recently. A multi-vendor patch upgrade is going on in July 2008 at the time of this writing and
many organizations are worried about this vulnerability. On the other hand,
use of third-party domains is a different kind of problem. It essentially promotes the susceptibility of users to phishing (and identity theft) since the bank is sending a message that it is OK to submit information to the bank
on a page that is on a domain other than where the customers normally start their login process.
Hopefully, the banks will stand behind their customers if a customer does get phished. But, there
are simple and better web site design options that should be considered, as we suggest in
our presentation. Several banks already use them and more should.
Have things changed since we collected the data in 2006?
We are getting that question a lot. If there appears to be a need, we hope to do this
analysis again, perhaps with a more detailed list of financial institutions. (Remember that the work
is unfunded, so it will be done on a time-available basis.) Our list is
currently probably biased towards larger banks; smaller banks may exhibit different behavior.
There is some evidence in another unpublished study, done independently of us, with fewer banks but more recent data, which will hopefully be out in the future -- that more banks are providing login boxes on secure pages. We became aware of the existence of this work only in the last few days after personal
communication by its author. The bad news appears to be that the percentage of sites with insecure login pages still was still found to be significant.
If one just looks at the largest banks in the country, one can still find several examples where the problem exists today (just try it out!).
We have some preliminary indications from repeat analysis of small number of banks on current state that the percentage of sites that use third
party services may have gone up since 2006. Furthermore, the number of sites that do not secure their contact pages continues to a
majority. So, overall, the state of security policies for online banking is still bad and could use significant improvement.
For the examples we used in our paper, here is the status ( as of July 26th):
- TCF Bank has made changes to the third-party domain from that in the paper. Now, a customer goes
to tcfexpress.com from tcfbank.com rather than a strange domain that existed in 2006 upon hitting the login button. One can also start at tcfexpress.com and stay on that domain.
- "Contact Us" pages continue to be on insecure pages at all the institutions used as examples in
the paper. No one in our examples has switched entirely to SSL (but we are aware of other banks that
appear to have done so for most of their site, so it is clearly feasible to do so now).
- One institution that we used in our paper switched from using social security numbers
to user-configurable user IDs, which is a significant improvement. But policies for emailing
statements continue to be ambiguous
- LaSalle Bank merged into Bank of America. Bank of America's site uses an SSL-protected
login page (try going to www.bankofamerica.com. Notice the https in the URL after redirection),
which is the right thing to do. Unfortunately, LaSalle Bank has not yet switched to SSL
for their login page or their site, though the contents changed drastically as a result of the merger.
Addressing this would be the right thing to do as soon as feasible.
( Update: Aug. 14th, 2008: LasSalle Bank now does redirect users to a a secure login page. Good change LaSalle! Chase has also started redirecting, though it has come to our attention that
it not yet perfect - it is still possible to get to an insecure login page. But, it is a good start from Chase!)