Department of Electrical Engineering and Computer Science professor Atul Prakash, as well as doctoral students Laura Falk and Kevin Borders conducted the survey. His study’s results come from a survey of 214 financial institutions’ web sites, which his team conducted in 2006. His team’s findings will be presented at Symposium on Usable Privacy and Security Meeting, to be held at Carnegie Mellon University on July 25.

While most banks have been good about maintaining site security – recent initiatives saw the addition of a secret question/answer system to nearly every bank’s web pages, and most banks dutifully place their infrastructure behind high-grade SSL encryption – Prakash’s study points out a number of seemingly minor, almost incidental flaws in the way banks web pages are designed and laid out:

• Allowing inadequate user IDs and passwords. Many web sites used social security numbers or e-mail addresses as acceptable login names – and many more failed to state a policy on password strength, or allowed weak passwords altogether. Twenty-eight percent of banks surveyed had this flaw.
• Sending customers’ sensitive information via e-mail. E-mail travels over a variety of uncontrolled, relatively insecure third party servers before reaching its recipient, says Prakash. Many banks offer password resets, online statements, and/or alerts to customers via e-mail, and this allows control over a bank account with as little as a hacked e-mail account. Thirty-one percent of banks surveyed had this flaw.
• Placing secure site controls, like log-in boxes, on unsecured web pages; failing to put log-in controls on an SSL-secured web page renders the site vulnerable to phishing and man-in-the-middle attacks. An SSL-secured log-in page would, in most cases, generate a certificate error if a customer attempted to log in through a tampered web page. In a wireless or proxied scenario, a man-in-the-middle attack lets attackers spoof a webpage without changing its URL. Prakash found 47 banks guilty of this.
• Posting contact information and security advice on unsecure web pages. Again, the lack of an SSL certificate allows an attacker to spoof pages containing with phone numbers of security tips – possibly advising unknowing customers to insecure behavior, or providing them with fake phone numbers. Fifty-five percent of banks surveyed had at least one occurrence of this.
• Breaking the “chain of trust”. Many banks redirect customers to other sites without warning, a tactic that engenders a context for poor security decisions, says Prakash. This is particularly common when some account functions are outsourced. The solution, he says, is to warn customers before redirecting them, or host all site functions on the same server. Thirty percent of banks surveyed were guilty of this.

“To our surprise, design flaws that could compromise security were widespread and included some of the largest banks in the country,” said Prakash. “Our focus was on users who try to be careful, but unfortunately some bank sites make it hard for customers to make the right security decisions when doing online banking.”

The study’s press release cites a recent FDIC Technology Incident Report, which describes 536 cases of “computer intrusion,” with an average loss of $30,000 per incident, in the second quarter of 2007.