Three Out Of Four Banking Websites Have Serious Security Flaws - Study
Source: Tom's Guide | Keywords: banking, website, security, study, university | Themes: Business
Ann Arbor (MI) - A soon to be released University of Michigan study will show that more than 75% of banking websites have serious security flaws. According to Atul Prakash, professor of electrical engineering and computer science, these flaws are design issues that cannot be quickly solved with a simple patch or upgrade.
Prakash, along with doctoral students Laura Falk and Kevin Borders, studied 214 financial institutions and found that the most serious issue was the placement of contact or security information on insecure pages. Prakash argues that this can easily lead to phishing attacks by the placement of bogus numbers that lead to scam artists.
Approximately 55% of the sites had this problem, while 47% placed login boxes on insecure pages. Prakash is recommending that banks use SSL protocol to secure their login pages. Why any bank still has a non-SSL login page is beyond me.
Rounding out the top five security problems are poor email security, broken chain of trust where banks redirect users to insecure outside sites and inadequate user id and passwords. 31, 30 and 28 percent of websites had these problems, respectively.
Of course security problems can erode public trust in banking websites and Prakash says, "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."
Prakash’s study titled "Analyzing Web Sites for User-Visible Security Design Flaws" will be released later this month on his website here.
-
Previous News Article
Social Networking Pictures Come... -
Next News Article
Shhh. We Have A Product But It's...
Just to be clear (and the FAQ on Atul Prakash's web page states this also), that any security system where the logon page is not SSL does not necessarily mean that the username/password is sent in clear text over the network, where anyone can snoop it.
Most of the time, if the logon page itself is not SSL, the postback that occurs when the user submits the username and password does use SSL. Thus, the username and password are protected.
Atul's point is that when the logon page is not SSL, it opens the site up to a phishing attack, because the logon page becomes easy to duplicate. With no SSL certificate to let the user know that they're on the legitimate site, the phishing site can be an exact replica.
It used to be very common to design sites this way, because if the the logon page uses SSL, then the entire page and associated graphics then all have to be delivered via SSL, which is computationally intensive and significantly reduces the number of simultaneous users that the web site can handle. Designing the site such that only the postback uses SSL reduces the computational load on the web server considerably.
Obviously, times have changed, both in terms of security and in available computational power, and there is no reason today that the entire site including the logon page cannot be delivered via SSL.
Just to be clear (and the FAQ on Atul Prakash's web page states this also), that any security system where the logon page is not SSL does not necessarily mean that the username/password is sent in clear text over the network, where anyone can snoop it.
Most of the time, if the logon page itself is not SSL, the postback that occurs when the user submits the username and password does use SSL. Thus, the username and password are protected.
Atul's point is that when the logon page is not SSL, it opens the site up to a phishing attack, because the logon page becomes easy to duplicate. With no SSL certificate to let the user know that they're on the legitimate site, the phishing site can be an exact replica.
It used to be very common to design sites this way, because if the the logon page uses SSL, then the entire page and associated graphics then all have to be delivered via SSL, which is computationally intensive and significantly reduces the number of simultaneous users that the web site can handle. Designing the site such that only the postback uses SSL reduces the computational load on the web server considerably.
Obviously, times have changed, both in terms of security and in available computational power, and there is no reason today that the entire site including the logon page cannot be delivered via SSL.
By the way, your commenting system is very messed up.
Attempting to submit a comment without logging in results in "An error occurred".
Submitting a comment after logging in just takes you to a "Page not found" after the submit, although the comment gets submitted anyway behind the scenes, but does not appear after the article.
Submitting a second time then results in a "Page not found" after the submit, and then both comments show up under the article.
I have to agree with some of the weak passwords and usernames. I hate it when a sight does not let me use letters, numbers and symbols with a length of 16 or more digits.
Conversely sights should allow any password whether it simply be "1" or "8015n*(&^%FDdahs^##%Hf246132bjweraihuio". Same goes with usernames I should be able to create a user name with any letters, numbers or symbols not just use my e-mail address.