Banks Abandoning SSL On Home Page Log-InsBanks Abandoning SSL On Home Page Log-Ins

Some of the biggest banks have abandoned the practice of posting their online account log-in screens on SSL-protected pages in an effort to boost page response time and guide users to more memorable URLs, a U.K. Web performance firm said Tuesday.

Netcraft noted that three of the largest banks in the U.S. -- Bank of America, Wachovia, and Chase -- as well as credit card giant American Express, now display their log-in forms on home pages not locked down with Secure Socket Layer (SSL).

According to Netcraft, companies are increasingly hesitant to use SSL's "https" on busy home pages, since SSL slows response time. Consumers, meanwhile, prefer easy to-remember URLs.

"In placing log-in screens on non-SSL home pages, banks are trying to have it both ways: fast page loading without the SSL-related performance hit," said Netcraft in an online briefing.

The username and password are still encrypted when sent to the bank's server, however; the form's Submit or Login button points to an SSL-enabled "https" URL.

The practice runs counter to the advice banks and others have been hammering into consumers for years: look for the padlock icon representing a secure, SSL page. With the recent flood of phishing and other identity theft attacks, that advice has been reiterated by the likes of the Federal Trade Commission (FTC) in its anti-phishing guidelines to users.

Banks are dealing with the contradiction by offering up additional information about their log-in procedures and how they secure data between the user's browser and the institution's servers.

"We protect information about your account with 128-bit encryption," says Chase in a page linked to from the log-in form on its non-SSL home page. American Express, meanwhile, is more explicit. "Please be assured that, although the home page itself does not have an "https" URL, the login component of this page is secure. When you enter your User ID and password, your information is transmitted via a secure environment, and once the login is complete, you will be redirected to our secure area."

But as Netcraft noted, Microsoft took the practice to task as long ago as April, when in an entry on the Redmond, Wash.-based developer's official Internet Explorer blog, program manager Eric Lawrence wrote that the idea was flawed and could be exploited by "man-in-the-middle" attacks. In particular, keyloggers could conceivably "leak" characters to another server as they're typed into a non-SSL log-in form before the Submit or Log-in button's clicked.

"The event model in HTML is pretty rich, and one of the things it can do is listen for keystroke events," wrote Lawrence "So, the bad guy could simply rewrite the log-in page HTML to leak keystrokes to a server he controls, every time a key is pressed. Unsecured log-in form + Man-in-the-Middle + 5 lines of JScript + Serverside keystroke collector = Bad News."