[Dataloss] Fringe: e-banking not yet secure

[macwheel99 at wowway.com]

Here is link to "Analyzing Web sites for user-visible security design flaws" 
by 3 authors: The professor & 2 graduate students.
http://cups.cs.cmu.edu/soups/2008/proceedings/p117Falk.pdf

The financial institutions that they studied
http://www.eecs.umich.edu/laura/webusability/websites.html

This paper is to be presented at the Symposium on Usable Privacy and 
Security (SOUPS) meeting at Carnegie Mellon University July 25.  
http://cups.cs.cmu.edu/soups/2008/

According to this other article, the study was done in 2006. Presumably (we 
would hope) some of the financial institutions have since upgraded their 
sites. http://www.eurekalert.org/pub_releases/2008-07/uom-sfi072208.php 

Relevant links here. http://news.yahoo.com/s/cmp/209600041

I originally saw the link on e-com sec & thought it also belonged on Data 
Loss, and Linked-In's Security before Implementation (I have not yet posted 
it there). http://packetfocus.com/proactive/index.php

Al Macintyre
Jack of all trades, master of some


security curmudgeon wrote
> ISN posted the article as well, cross-posting my reply.
> 
> : Security flaws plague majority of e-banking sites 
> : http://www.finextra.com/fullstory.asp?id=18764
> : 
> : Over 75% of banking Web sites contain fundamental design flaws 
> that : could put customers at risk from cyber thieves, according to 
> a study (of : 214 bank web sites)conducted by researchers at the 
> University of : Michigan.
> 
> Unfortunately, all I can find are articles mentioning the study. It 
> still isn't available on Atul Prakash's home page [1]. Since all we 
> have to go on right now are sound bytes and brief summaries, it is 
> very easy to tear large holes in the results. I encourage Prakash 
> and his team to make the original research more readily available.
> 
> : The flaws are not bugs that can be easily fixed with a patch, but 
> are : systemic, stemming from the flow and layout of the sites.
> 
> The flaws are often very easy to fix, and do not require much 
> work from the bank.
> 
> : 47% placed secure login boxes on insecure pages.
> 
> While a bad practice, this doesn't translate to "attackers can get 
> access to customer information" necessarily. "He says this allows 
> hackers to re-route data entered in the boxes or create a spoof page 
> to harvest information." First, to re-route data entered in the 
> boxes relies on something more than a mixed HTTP/S page. Exploiting 
> cross-frame scripting in some browsers would be a good idea, but 
> that can be blocked regardless of the page being served over SSL. 
> Second, bad guys can spoof pages regardless of the presence of SSL,
>  yet Prakash suggests otherwise.
> 
> "Prakash says 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."
> 
> Certainly a risk, but the amount of customers accessing their bank 
> over unsecured wireless are probably very minimal and changes the 
> requirements of exploitation considerably.
> 
> : 55% put contact information and security advice on insecure pages.
> 
> Again, having a static /contact.html on the legitimate domain, not 
> served over SSL is not a vulnerability, and does not lead to 
> customers being at risk from "hackers getting access to customer 
> information". The summary and introduction to the article is poorly 
> worded and misleading.
> 
> : Some banks use social security numbers or e-mail addresses as user 
> IDs.
> 
> This is definitely a bad practice and commonly seen, but this is 
> half of the information needed to authenticate. Brute forcing a list 
> of login IDs is time consuming, brute forcing valid passwords for 
> them on top of that is very time consuming. There are certainly 
> controls that can be put in place to make harvesting attacks more 
> costly, regardless of the login name scheme.
> 
> : 28% don't state a policy on passwords, or allow weak passwords.
> 
> Yes, they should state their policy, but how many of the 28% don't 
> state the policy yet enforce a relatively strong one? This number is 
> a poor metric.
> 
> I have a hard time believing that Prakash and his team got 
> permission to test 214 bank web sites. If they did, it was still 
> done without authentication based on the results in the article. The 
> few results they do have are not near the risk implied by the 
> summary wording or have caveats on exploitation. None of them are 
> real eye-openers as each one would likely result in the compromise 
> of a handful of accounts. While certainly bad, that is insignificant 
> compared to an SQL injection or privilege escalation attack that 
> allowed cross-user information disclosure 
> (or manipulation).
> 
> All said and done, this research is quite limp so far.
> 
> - jericho