WebApp Sec mailing list archives

Re: Growing Bad Practice with Login Forms


From: "Jason Coombs PivX Solutions" <jcoombs () PivX com>
Date: Tue, 27 Jul 2004 21:24:23 +0000 GMT

The problem that is caused by this bad practice has nothing at all to do with the presence or lack of a secure padlock 
SSL icon -- the problem is that the server authentication provided by SSL only verifies that the FQDN of the 
SSL-secured server matches that which is found inside the server certificate that is provided to the client.

When the user types http: rather than https: to make the crucial first contact with the server, they forfeit all 
authentication (and much of the security) afforded by SSL, because they allow a DNS lookup and an unathenticated http 
connection to control which https URL will be used in subsequent requests.

It should be impossible for users to contact any https: url during the initial request that sets up a new session 
unless the user has typed in “https” and the trusted FQDN themselves.

This won't solve all certificate spoofing, theft, or bad CA procedure flaws but it will put a stop to users willfully 
giving up the benefit of SSL just because they (and the server operators) can't be bothered to type https:

Jason Coombs
Jcoombs () PivX com

-----Original Message-----
From: "Thomas Schreiber" <ts () securenet de>
Date: Tue, 27 Jul 2004 16:56:43 
To:<webappsec () securityfocus com>, "Mark Curphey" <mark () curphey com>
Subject: RE: Growing Bad Practice with Login Forms

I see a problem at the semantic level: People should be educated to look at
the unfakeable Browser Icon - and not at some promise inside the webpage -
to convince themselves that the connection is secure *before* they send
sensitive data. What if the button promises 'Secure Login' but after sending
they realized it wasn't - it's to late, the password may already have been
sniffed by some colleague on the same wire.

If people learn at websites they trust, that the browser icon *always*
indicates a secure connection before they send sensitive data, then they
will automatically behave correctly if they encounter a website where this
is not the case: they get suspicious and think twice about clicking the send
button or not.

So I second: bad practice.

Beste Gru?e
Thomas Schreiber
____________________________________________________________
SecureNet GmbH - http://www.securenet.de
+49 89/32133-610
mailto:ts () securenet de


  > -----Original Message-----
  > From: Mark Curphey [mailto:mark () curphey com]
  > Sent: Tuesday, July 27, 2004 3:56 PM
  > To:
  > Subject: Growing Bad Practice with Login Forms
  >
  >
  > 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.


Current thread: