Re: Growing Bad Practice with Login Forms

["Jason Coombs PivX Solutions" <jcoombs () PivX com>]

> In that example as I mentioned it
> is (I checked the HTML post location
> and it was).

You *think* you checked the post location...

Have you not seen attackers who anticipate security-aware types scanning page source before “trusting” the page? It is 
common now for decoy HTML to be placed at the top of the page, and for client-side scripting, formatting and 
HTML/script comment tricks to be used to obscure and conceal the fact that the HTML you're looking at is not in fact 
the HTML that the browser will interpret...

You feel like you're smart enough to read any page source and understand it quickly, but you're not. Nobody is.

Jason Coombs
Jcoombs () PivX com

-----Original Message-----
From: "Mark Curphey" <mark () curphey com>
Date: Tue, 27 Jul 2004 15:56:38 
To:"'Merlijn Tishauser'" <merlijn () begeleidingentraining nl>,       <webappsec () securityfocus com>
Subject: RE: Growing Bad Practice with Login Forms

My original reply has yet to make it through to the list but let me cut and
paste it below to see if it jumps the queue.

There is absolutely no issue with SSL and I understand it just fine ;-) That
stuff is all old news and the protocol was designed to prevent the sort of
issue people seem to have jumped on. If you don't know how it works here is
a free chapter from the guy who wrote the RFC.

http://www.rtfm.com/sslbook/chap9-sample.pdf


Rogan and others understood the issue.

Let me put it this way. If a man wearing jeans and a t-shirt stopped you on
the street and said "hi I work for bank X, give me your ATM card and I will
get some cash for you" what would you do so? I doubt it. If you went into a
branch building and was asked for your ATM by a teller then the answer would
and should be different. In the first case you have no idea where the
stranger is going to go with your card.

<snip from my reply earlier>
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: Merlijn Tishauser [mailto:merlijn () begeleidingentraining nl] 
Sent: Tuesday, July 27, 2004 12:14 PM
To: webappsec () securityfocus com
Subject: Re: Growing Bad Practice with Login Forms


On 27-jul-04, at 17:08, Dan C Crawford wrote:

> I just ran a packet capture of logging into a service that uses a 
> nearly identical form as found on ISACA. It definitely setup the 
> secure SSL connection prior to transmitting my logon data.

I had to design my own loginform couple of weeks ago.
I was puzzled by the same question as the original poster was.

But I totally agree with the sender above.
I set up ethereal on both my webserver as on a client.
Er was absolutely no exchange of login data before the SSL handshake or 
after cancellation of the transaction.


my 0.02 cents

Merlijn