Financial Site Security Research Weak On Methodology and Timeliness

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