I recently came across a paper by Atul Prakash Analyzing Websites for User-Visible Security Design Flaws which discusses some findings in a recent survey of 214 financial institutions conducted in 2006. The origin of the study came about when Prakash notices many of the below listed flaws in his own financial institutions websites.

The top design flaws that Prakash and his team were looking for were:

• 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.

One of the focuses is the fact that these flaws aren’t exactly bugs, but actual flaws in the designs. Many can be remedied, but these are the kinds of things that should have been considered in the design phase.

It only goes to show that planning is as important as implementation.

This entry was posted on Monday, July 28th, 2008 at 5:59 pm by Tim Donaworth and is filed under general. You can follow any responses to this entry through the RSS 2.0 feed. Both comments and pings are currently closed.