Re: Growing Bad Practice with Login Forms

["Toro, Daniel" <tcvx () taconvino cl>]

First of all, I would like to thank Yvan for thinking about us, the "less  
experienced".  Even when most of Security Pros out there think of it as a  
"must be known" thing, making a point clear is not less important, IMO.
Second, I was thinking about this "unfakeable Browser Icon".  Is it really  
unfakeable?  Maybe the certificate is hard (near impossible?) to fake, but  
the locked padlock appears the same in every HTTPS page, wich immediatley  
makes me think of some kind of bogus certificate, intended only to display  
this famous icon
(http://news.click-now.net/58_Phishing%20scams%20get%20more%20sophisticated.htm).
I've never met a user double-clicking this icon to check if the  
certificate is real.

So, back to the main thread here: Is this the best way to get user names  
and passwords?  I mean, a couple of redirections server side, skipping  
HTTPS, is just as safe as HTTP, right?

Please, if I'm way off track here, let me know, so I can keep learning  
from my mistakes.


On Tue, 27 Jul 2004 11:24:54 -0500, Yvan Boily <yboily () seccuris com> wrote:

> This is not a reliable suggestion; the secure icon for an HTTPS  
> connection
> indicates only that the CURRENTLY viewed page uses SSL, not that any  
> other
> pages use it.  Most users disable the warning box that notifies them that
> they are moving between encrypted and unencrypted sites, so the  
> observation
> that the site is encrypted *at this point* is not a valid means for being
> trustworthy.  This is crucially important in the case
>
> Furthermore, I think it is important to clarify something on the symantic
> level.  As security professionals we need to stop using marketing and
> user-friendly terms for what we know not to be true.  The browser icon
> indicating that SSL is in use is a recognition of the fact that the data
> being exchanged is encrypted, not that it is secure.  Many people on this
> list are aware of the difference, however using the two interchangeably  
> when
> discussing the security of protocols such as HTTP and HTTPS is misleading
> for people with less experience.  We cannot always educate users about  
> the
> nature of information security, but we should do our best to prevent
> confusion among those trying to learn.
>
> From a secure programming perspective, there are a number of means to
> mitigate phishing attacks which attempt to modify the use of forms
> transmitted via HTTPS:
>
> 1. Use SSL to ensure the authenticity of a web page
>         + sufficiently savvy users can inspect the certificate to ensure
> that the site is who it claims to be
>         + using SSL 2 or TLS provides the benefits of public key encryption
> (authentication, integrity, privacy, non-repudiation)
>         - only protects contents of web page in transit
>                 * proper application of input validation and output
> transformation mitigates attacks at the client end
>         - all components of the web page must be loaded via SSL or the
> security benefit is lost
>                 * loading images, advertisements, etc via HTTP can leak
> cookies and can reveal SIDs etc
>
> 2. Input validation
>         + ensures that all data complies with what is expected
>         + provides first line of defense against injection attacks (XSS,
> SQL)
>         - can interfere with functionality and useability if validation
> techniques are too paranoid
>                 * I don't see this as a negative.
>         - depending on validation mechanisms they can be fairly time
> consuming
>                 * buy a better webserver.
>
> 3. Output filtering
>         + ensures that all user entered data is translated from raw data to
> HTML entities, radically increasing the difficulty of XSS attacks
>         - can place a huge load on webserver depending on the volume of user
> entered data being translated and mechanisms used to translate between  
> the
> two
>
> These are just broad overviews of the techniques that can be used (and  
> are
> used in applications which I have designed and implemented).  There are a
> huge number of other concerns, such as rotating session identifiers when
> switching between encrypted and unencrypted connections, preventing  
> session
> fixation attacks, and other session hijacking prevention techniques.
>
> There also seems to be a general concern over how HTTPS encapsulates an  
> HTTP
> transaction.  The HTTPS protocol establishes the connection using the
> following (basic description) steps:
>
> 1. Client sends SSL request
> 2. Server responds with certificate and its public key
> 3. If the certifcate and key match *OR* the client blindly accepts the
> public key the client will generate and encrypt a symmetric key for
> communications using the servers public key and transmit it back to the
> server.
> 4. The server decrypts the key and uses the key to encrypt data exchanged
> for the HTTP session.
> 5. Once the server has the encryption key the server accepts an HTTP  
> request
> that is encrypted and provides the HTTP response in an encrypted format.
>
> If a web page is actually using SSL the server will not receive  
> information
> prior to establishment of the encrypted channel for the HTTP exchange.
>
> I have taken the liberty of including a basic SSL transaction using CURL  
> and
> plaintext packet dumps (my tool of choice for this is ipex) to illustrate
> this.
> .
> .
> .
>
>
> -----Original Message-----
> From: Thomas Schreiber [mailto:ts () securenet de]
> Sent: Tuesday, July 27, 2004 9:57 AM
> To: webappsec () securityfocus com; Mark Curphey
> 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.