The tests used in a paper reported on last week were questionable back in 2006 when the data was collected. Today they are merely interesting, but not all that illustrative of reality.A study by researchers at the University of
Michigan finds that more than 75% of bank web sites had at least one design
flaw that could allow attackers to compromise users accounts or their
identities. Unfortunately, the data was collected in November and December of
2006. The research was presented
in a paper last week at the Symposium On Usable
Privacy and Security at Carnegie Mellon.
Some of the problems they report on, such as login forms on non-https pages,
have been addressed by many banks since then. I wrote about that specific
problem at the time (that blog is no longer online), noting that
many large banks had their home pages, and login forms on them, on insecure web
pages for performance purposes. Now this is comparatively rare, although
chase.com still does it; in fact, even if you specify https for your Chase URL,
you are redirected back to the http page. But many banks, such as Bank of
America, which used to use insecure pages, now not only use https pages, but
have added Extended Validation SSL certificates so that you get the added
feedback of the green address bar. Things have changed a lot since 2006.
The research also complains about bank sites where the Contact Us and
Security Information pages are on non-https pages. This is more common now than
the login problem, but how serious is it really? The notion is that attackers
could put in a fake phone number and set up their own fake call center, but it's
not clear how they would get the user to visit that page; they could just set up
a phishing site on any other domain and put up whatever pages they wish. It's
not the same as with a login page, where an attacker could conceivably sniff
unencrypted sensitive data off the network.
Another problem in the list was where the bank redirects users to a different
domain for some portion of a transaction, which occurred on 30% of banks. This
is indeed a bad idea, but I suspect it has diminished over time, especially as
banks have adopted EV-SSL certificates, which can only be credible if they are
present for the entire transaction. The researchers provide one example both in
the text of their paper and in screen shots, of TCF Bank, which has this problem. I can
confirm that their description of it is largely still accurate. This bank's use
of SSL is clearly inadequate.
28% of bank sites allowed users to specify inadequate usernames and
passwords. They specifically looked for banks that allowed social security
numbers or e-mail addresses as usernames, as well as those that allowed weak
passwords or had no policy on passwords. Weak passwords are certainly a problem,
although they provide no numbers on how many banks allowed them. Using a social
security number as a username sounds like a very bad idea indeed, but I can't
imagine why an e-mail address would be a bad username. If it's just that the
userid can be guessed, so what? It's the password strength that matters. And
even when weak passwords are allowed, as the researchers themselves point out,
the problem can be mitigated by locking out the account after some number of
failed logins. They did not look for this capability in their research.
Finally, the research talks about sensitive information e-mailed to users,
specifically e-mailing passwords and bank statements. E-mailing actual passwords
is certainly a serious problem, but statements are not so clearly a problem. As
the paper itself says, a bank might offer to e-mail the actual statement, a
notification that a statement was available on the web site, or a link to that
statement online. The researchers don't know which these banks offered, and some
are not a problem at all, but the offer of any of them is a bad sign for the
research. The methodology for this item is the weakest of the 5 and the least
defensible in the paper.
The researchers chose these flaws because they were able to develop automated
tests for them. There are, perhaps, more important issues for banks to be
working on, but the researchers did not test them because they could not
automate those tests.
I also have a problem with the way the research tends to combine two problems
into a single result number. In many cases I would argue one of the problems is
a serious one and the other is not, but they don't break down the results based
on the individual problems, so it's hard to know how much concern one should
have for that problem.
There is useful information in this study and most, if not all of the
vulnerabilities are worthy of concern. But at this point in time you can't take
their results numbers seriously. Such research needs to be more timely.
Security Center Editor Larry Seltzer has worked
in and written about the computer industry since 1983.
For insights on security coverage around the Web, take a look at eWEEK.com
Security Center Editor Larry Seltzer's blog Cheap Hack
