1996-04-13 - Re: WWW User authentication

Header Data

From: Jeff Barber <jeffb@sware.com>
To: stillson@ashd.com (Chris Stillson)
Message Hash: 85ff6f3945c25ddf8611ffd2cc1b2c763b6abcabf0045d80f8409204dc46954f
Message ID: <199604101707.NAA23185@jafar.sware.com>
Reply To: <199604092100.QAA21158@bach.ashd.com>
UTC Datetime: 1996-04-13 19:07:49 UTC
Raw Date: Sun, 14 Apr 1996 03:07:49 +0800

Raw message

From: Jeff Barber <jeffb@sware.com>
Date: Sun, 14 Apr 1996 03:07:49 +0800
To: stillson@ashd.com (Chris Stillson)
Subject: Re: WWW User authentication
In-Reply-To: <199604092100.QAA21158@bach.ashd.com>
Message-ID: <199604101707.NAA23185@jafar.sware.com>
MIME-Version: 1.0
Content-Type: text/plain


Chris Stillson writes:
> 
> At 11:58 4/9/96 -0400, Jeff Barber wrote:
> >Brian C. Lane writes:
> >
> >>   I just finished writing a cgi script to allow users to change their login
> >> passwords via a webpage. I currently have the webpage being authenticated
> >> with the basic option (uuencoded plaintext). MD5 would be nicer, but how
> >> many browsers actually support it?
> >
> >AFAIK, none.  I don't see how this would be helpful anyway.  If you 
> >MD5 the password, I won't be able to snoop the password off the wire,
> >but I can simply snoop the MD5 hash off the wire instead and since 
> >that's what your authentication check must now be against, what does
> >this buy you?

> Well, that isn't exactly how digest authentication works.
> In fact mister barber should figure out what he is talking about
> before saying anything.  But, you can't really use a hash function
> to send the new password.  

OK.  I suppose I deserved this -- I didn't make the leap from "MD5" to digest
access authentication.  I've studied up now.  Still, as you say, digest
authentication won't protect the password modification scenario.


> >>   When the user changes their password, the form sends their name, old
> >> password, and new password with it, in the clear. This is no worse than
> >> changing your password across a telnet connection, but I'd like it to be
> >> more secure, but useable by a large number of browsers.

> >Well, if you use SSL, it's useable by a "large number of browsers" since
> >Netscape has such a large share of the browser market.  And then all of
> >the things you're doing w.r.t. authentication are hidden, at least from
> >casual eavesdroppers and others too if you use more than the 40-bit option.
> >There's really no other choice to reach a large number of browsers.

> Once again mister barber is being an idiot.  netscape is not a "large number
> of browsers".

This, on the other hand, was both uncalled-for and incorrect.  Netscape
browsers certainly do account for a large majority of the total browsers.
If a solution doesn't work with Netscape, most people would agree that it
isn't "useable by a large number of browsers".  And, in any case, Netscape
is not the only browser to implement SSL.  Several other commercial
browsers also claim to support SSL and I have even heard that there is a
version of Mosaic that uses SSLeay.


>                He is right that ssl is probably a good way to go. (shttp would
> be better :) )

SHTTP might be better if it didn't have to be "useable by a large number
of browsers" -- since Netscape doesn't support SHTTP.  (I'm sorry that you
apparently find Netscape's success so frustrating, but it is a fact.)


-- Jeff





Thread