RE: Growing Bad Practice with Login Forms

["Lane Weast" <lweast () leeclerk org>]

I think the point is that you have to enter your password in the non
secured page (http:) and unless you view the code you don't actually
know if it is going to be submitted secure (https:), so should we tell
our non technical users.. Only use your password on pages that are
secured. You can tell a page is secured by the https: and by the lock
that indicates a secure connection. 
Except where it is secure but doesn't have HTTPS and a lock.

Yah.. That will go over real well... :p

Lane





-----Original Message-----
From: Ian [mailto:webappsec2 () fishnet co uk] 
Sent: Tuesday, July 27, 2004 10:13 AM
To: Mark Curphey; webappsec () securityfocus com
Subject: Re: Growing Bad Practice with Login Forms


On 27 Jul 2004 at 9:55, Mark Curphey wrote:

> I am seeing more and more sites implementing a bad practice with login

> forms.
>
> To pick on a high profile site that should know better take ISACA as 
> an example.
>
> http://www.isaca.org/
>
> In the top left hand corner you will see their secure login button and

> a graphical padlock embedded into the HTML. Of course if you look at 
> the form tags, this does indeed submit the form over SSL and in the 
> process the SSL handshake checks the certificate and my browser should

> verify that I am indeed sending my password to isaca.org.
>
> 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.
>
> I have added the issue to the OWASP Pen Test CheckList.

Hi,

It was my understanding that the SSL session is initiated before any
request is sent.  Therefore 
the username / password would be protected since any failure in the
handshake would occur ( 
and be flagged by your browser ) before the data is sent.


Please correct me if I'm wrong because I may need to do some updates...
;)

Regards

Ian
--