Netcraft recently wrote an article about online banking websites switching away from SSL login forms toward less secure login pages. Back in May, Mozilla programmer Jesse Ruderman wrote about the same issue. My bank, Bank of America, defends the practice by claiming:
The moment you click Sign In and before your ID and passcode leave your computer, we encrypt them using Secure Sockets Layer (SSL) technology. That means only Bank of America has access to your ID and passcode.
There are two problems with this practice: One fairly obvious, and one slightly less obvious. The first problem is simple: How does the user know that the form is being submitted via HTTPS? Most browsers have no such UI cue. (Pretty much everyone turns off the "Warn when sending unencrypted form data" option within 2 minutes of installing the browser.) Even supposing there was a UI cue that the form was targeted at a HTTPS page, how could the user know that it was going to the right HTTPS page? If the login form was delivered via HTTP, there's no guarantee it hasn't been changed between the server and the client. A bad guy sitting on the wire between the two could simply retarget the POST to submit to a HTTPS site that he controls. Oops.
In the meantime, you can use this SSL version of the Bank of America login page.
 When I explained why Lawrence's example of a man-in-the-middle attack involving malicious DNS servers was a hypothetical problem, I received a boilerplate response for phishing inquiries, explaining that "the website I had visited was not operated by Bank of America" and that I should call them if I had submitted any of my banking information. Since I had both clearly noted that the example was hypothetical, and provided a link to the IEBlog post, this response made me consider closing my account. If Bank of America's customer service representatives do not take the time to even read customer inquiries, how much care are they taking with my money?