Financial Site Security Research Weak On Methodology and Timeliness

By Larry Seltzer  |  Posted 2008-07-27 Print this article Print

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 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 Security Center Editor Larry Seltzer's blog Cheap Hack

Larry Seltzer has been writing software for and English about computers ever since—,much to his own amazement—,he graduated from the University of Pennsylvania in 1983.

He was one of the authors of NPL and NPL-R, fourth-generation languages for microcomputers by the now-defunct DeskTop Software Corporation. (Larry is sad to find absolutely no hits on any of these +products on Google.) His work at Desktop Software included programming the UCSD p-System, a virtual machine-based operating system with portable binaries that pre-dated Java by more than 10 years.

For several years, he wrote corporate software for Mathematica Policy Research (they're still in business!) and Chase Econometrics (not so lucky) before being forcibly thrown into the consulting market. He bummed around the Philadelphia consulting and contract-programming scenes for a year or two before taking a job at NSTL (National Software Testing Labs) developing product tests and managing contract testing for the computer industry, governments and publication.

In 1991 Larry moved to Massachusetts to become Technical Director of PC Week Labs (now eWeek Labs). He moved within Ziff Davis to New York in 1994 to run testing at Windows Sources. In 1995, he became Technical Director for Internet product testing at PC Magazine and stayed there till 1998.

Since then, he has been writing for numerous other publications, including Fortune Small Business, Windows 2000 Magazine (now Windows and .NET Magazine), ZDNet and Sam Whitmore's Media Survey.

Submit a Comment

Loading Comments...
Manage your Newsletters: Login   Register My Newsletters

Rocket Fuel