RE: Growing Bad Practice with Login Forms

["Mark Curphey" <mark () curphey com>]

I guess I didn't do a clear job of explaining my issue.

It is true if it is sent via HTTPS the SSL negotiation takes place before
the HTTP happens so it wouldn't be sent. In that example as I mentioned it
is (I checked the HTML post location and it was).

But a phisher can easily create a site that looks exactly the same as the
original and claims to be submitting the page to an SSL location using the
icon. The form actually gets submitted to the phishers site and he captures
the username and password (no SSL so no browser error, just the padlock icon
in html). 

The correct flow should be as follows.

User should validate who is asking for the username and password (SSL auth)
When satisfied it is a valid request he can send his shared secret to the
3rd party who validates it and accepts or rejects user authn

In the bad sites the user assumes it using SSL but doesn't know it isn't
until its too late (or he / she checked the HTML (which won't happen))

Sure the good site could request the username and password from a SSL served
page and then submit it to a non-SSL phishing site but at that point you
knew who did it.

Its like those ATM's in corner shops. I am not putting my ATM card in one to
see if it connects to the banks ATM network with my PIN. By the time I
realize it wasn't a Bank of X ATM its too late. I want to only put my card
into genuine bank ATM's (not a good analogy as verifying the authenticity of
an ATM is not a minor problem and out of scope here but ...)

If users continue to happily submit usernames and passwords to
http://bankx.com, Average Joe  will continue to fall prey to phishing scams
IMHO.




-----Original Message-----
From: Konstantin Ryabitsev [mailto:icon () phy duke edu] 
Sent: Tuesday, July 27, 2004 10:12 AM
To: Mark Curphey
Cc: webappsec () securityfocus com
Subject: Re: Growing Bad Practice with Login Forms

On Tue, 2004-07-27 at 09:55 -0400, Mark Curphey wrote:
> But at that point its too late. The check for server authentication is 
> done after I have sent by username and password. This IMHO is a bad 
> practice that has started to creep into other sites including online
banking.

Not really. SSL verification is done before the HTTP headers are sent to the
server (same reason why you can't have name-based SSL virtual hosting), so
if there is SSL cert mismatch, your browser will alert you and if you cancel
the connection then, the server won't see any of your data.

In fact, presenting the login form on the SSL page won't win you anything,
since there is no guarantee that you will submit your data to the same
SSL-enabled server than the one that sent you the login form.

Regards,
--
Konstantin Ryabitsev
Duke University Physics