Consumer Alert: Report Says Bank Web Sites Insecure

In a study by the University of Michigan researchers found 75 percent of the banking websites it looked at had "at least one design flaw" that could turn the nightmare of identity theft into reality.

According to the study the bank site vulnerabilities it pinpointed are found with the bank sites' webpage design. Researchers say a poorly designed bank sites can "silently" redirect users to third-party sites and display "secure" login boxes on insecure Web pages. Worse, some banks wrongly require its customers to use Social Security numbers or e-mail addresses as logins which a hacker might easily conclude is a victim's default user name.

I can only guess this kind of security flaw is low on the priority list for banks these days who are currently dealing with large-scale mortgage fraud, check fraud, and a foreclosure crisis right now. However, small-scale hacking can have tremendous consequences for the individual customer, and the bank as well, once flaws are exploited.

My first instinct was to check the websites of the very large banking institution to which I belong. To my dismay, the login page was left insecure. While my bank makes a good effort to encourage unique user ID's and passwords, and require email confirmation when I use an outside computer, the login page lacks the "https://" that I find on the Web pages, post-login.

Fortunately, I don't have much to steal and my identity isn't worth that much anymore, either.

The study was conducted by Professor Atul Prakash and students at the University of Michigan's Department of Electrical Engineering and Computer Science. Web sites of 214 financial institutions were examined. None of the "problem" banks were identified.

Here are some excerpted highlights of the study:

? Placing secure login boxes on insecure pages: A full 47 percent of banks were guilty of this. A hacker could reroute data entered in the boxes or create a spoof copy of the page to harvest information. In a wireless situation, it's possible to conduct this man-in-the-middle attack without changing the bank URL for the user, so even a vigilant customer could fall victim. To solve this problem, banks should use the standard "secure socket layer" (SSL) protocol on pages that ask for sensitive information, Prakash says. (SSL-protected pages begin with https rather than http.) Most banks use SSL technology for some of their pages, but only a minority secure all their pages this way.

? Putting contact information and security advice on insecure pages: At 55 percent, this was the flaw with the most offenders. An attacker could change an address or phone number and set up his own call center to gather private data from customers who need help. Banks tend to be less cautious with information that's easy to find elsewhere, Prakash says. But customers trust that the information on the bank's site is correct. This problem could be solved by securing these pages with the standard SSL protocol.

? Having a breach in the chain of trust: When the bank redirects customers to a site outside the bank's domain for certain transactions without warning, it has failed to maintain a context for good security decisions, Prakash says. He found this problem in 30 percent of the banks surveyed. Often the look of the site changes, as well as URL and it's hard for the user to know whether to trust this new site. The solution, Prakash says, is to warn users they'll be moving off the bank's site to a trusted new site. Or the bank could house all of its pages on the same server. This problem often arises when banks outsource some security functions.

? Allowing inadequate user IDs and passwords: Researchers looked for sites that use social security numbers or e-mail addresses as user ids. While this information is easy for customers to remember, it's also easy to guess or find out. Researchers also looked for sites that didn't state a policy on passwords or that allowed weak passwords. Twenty-eight percent of sites surveyed had one of these flaws.

? E-mailing security-sensitive information insecurely: The e-mail data path is generally not secure, Prakash says, yet 31 percent of bank Web sites had this flaw. These banks offered to e-mail passwords or statements. In the case of statements, users often weren't told whether they would receive a link, the actual statement, or a notification that the statement was available. A notification isn't a problem, but e-mailing a password, a link or a statement, isn't a good idea, Prakash says.

CREDIT: PC World contributor Sarah Pappalardo filed this blog.

Comments

Post a comment Post a comment

0 / 1000 max characters