kasia in a nutshell

A waste perhaps, but there are those who will note the lack of some icon which says 'encrypted' on the initial page and think submitting information will continue to be in the clear...

"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."
>>>>
Um, wouldn't doing something like that REQUIRE HACKING THE BANK'S SERVER IN THE FIRST PLACE (e.g. "rewrite the log-in page")? That's not a man-in-the-middle attack.

BTW, Kasia your comments aren't using https!! AAIIIEEEEEEE!!!

Kasia, sure, *encrypting* the login page is a waste, but *signing* it (the other effect of HTTPS; providing a cryptographic assurance that the page really came from who it appears to have come from) is not a waste.

Mike, no, what Lawrence suggested would *not* require hacking the bank's server. It would only require getting "in-the-middle" (as it were), messing with the network traffic, replying to packets before the remote server does. Often easy to do, e.g. sitting in the same wi-fi-enabled internet cafe as the client. See
http://www.evilscheme.org/defcon/ for an account of such traffic meddling being done quite successfully at Defcon using airpwn: http://sourceforge.net/projects/airpwn

Now, not every unprotected login page in the world will have people doing that, sure. But that's not because it's technically infeasible; it's just because nobody is bothering to do it, on most sites. If you're a bank or PayPal or such, that's not really something you want to rely on.

Can't they just throw hardware at it? Is SSL such a CPU hogging beast compared to regular pages? Some sites I use (like REgisterFly) are quite slow in https, while with others it's not too noticeable.

Mike: SSL has a whole slew of authentication machinery built in. Why? Wouldn’t tampering with the communication require hacking the remote server? Uh, obviously not. So too does it not require hacking the remote server to tamper with their login page.

Requiring login pages to be encrypted is absolutely justified because decrypting them puts them through the SSL authentication process, so that you know *which* server the content came from and that it was *not* tampered with. That there’s no sensitive data being encrypted is irrelevant in this case.

not knowing much about this...I think a login page should be encrypted, as stated above, just becuase you want to *know* that the login screen you are on is signed by that site (even though it can probably spoofed as well)

as a user, I kinda like to see my firefox address bar turn yellow on pages I think should be secured.

So there is my 2 bits worth :)

crap, can't edit...Just read the title of the article...if it's a bank...I'd rather wait the extra 3.232 seconds for the page to load then risk a login page that's not signed by the bank...for what it's worth....Yeah I just loaded my bank's login page...came right up, and has Verisign signed ecryption...and it logged in fast...in a world where most people have broadband...is a slightly faster login screen something we need to care about?

all our login pages here are SSL encrypted. I think most people click of the "You're submitting info over the net encrypted" box

I guess is more the servers that these bank pages reside on that they are worried about...one more ecyrpted page is that much more work for the server everytime someone logs in.