Re: Must we authenticate login forms (using SSL?)?

[Rogan Dawes <discard () dawes za net>]

Nathaniel S. H. Brown wrote:
> > On Thu, Sep 29, 2005 at 10:02:00PM -0700, Nathaniel S. H. Brown wrote:
> >
> > > I have created a very unique, yet simple method of a form 
> >
> > encryption 
> >
> > > that provides the same mechanism that the public/private 
> >
> > key entails.
> >
> > > Check out my just published release at 
> > > http://www.nshb.net/secure-form-post-with-javascript-without-ssl
> >
> > erm... this sounds like a plain old challenge-response 
> > mechanism. Or maybe I don't understand what you mean with 
> > "private key" and "public key" in your description.
>
>
> Surprise, surprise. I had no idea about this RFC. The principles of RFC 2195
> are exactly along the same lines as what I had implemented with the web
> post. However, it seems as though the downside is that the secret with my
> 1.0 as well as the RFC 2195 has to be available in plain text at both ends
> exclusively.
>
> Within the news post referenced above, I made alluded to the next iteration,
> which involves a more complex and secure authentication mechanism which does
> not require the password to be stored as plain text within the database, but
> will still be used on the client side as they need to manually acknowledge
> they know what it is to properly authenticate. Only on the client computer
> which creates the hash that is transmitted has access to the clear text
> password.
>
> To adjust the system would be quite simple. Based on a fixed username, when
> a user creates or changes their password, the password field associated to
> that user record would store a md5(username+password) in the database. Now,
> on the client side, it uses a precomputed hash as the password which
> combines the clear text password with the username combined to form the
> hash. So on the form, the insertHash JavaScript function would md5(username
> + md5(username + password) + timestamp + publicKey), and on the reverse, the
> server side script would compare against md5(post.username +
> database.password + post.timestamp + post.publickey).
>
> This would result in the password being stored in an encrypted, MD5 format
> within the database, and still transmit the private key (password) through
> the same fashion as CRAM-MD5 in a double layer MD5 hash ensuring its
> security.
>
> - Nathan

The core problem with any security mechanism that is implemented using 
"stuff" (Javascript, Java applet, etc) that is downloaded from the 
server that you are visiting is that any man in the middle attack can 
simply remove that mechanism, and substitute it with their own.

e.g. My bank logon script performs an MD5 hash of the username and 
password before sending it to the bank. The MITM tricks me to visiting 
their own site, and just "proxies" the comms to the real site. However, 
they strip out the MD5 hashing script,and replace it with an "identity" 
function (i.e. the output is the same as the input). When the MITM 
receives the form submission, it is trivial for them to extract the 
username and password from the form, replace it with the MD5 hash 
expected, and pass it on to the real bank.

I had started implementing/experimenting with using Secure Remote 
Password (http://srp.stanford.edu/) for authentication to a secure web 
site, with the idea that the password is never transmitted in clear, or 
in a recoverable form. However, this stumbling point convinced me that 
I'd be wasting my time!

One reason that SSL client certs offer real protection is that they are 
not controllable by page content, and do not rely on something that 
comes down from the site you are visiting.

Regards,

Rogan