WWW User authentication

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?

  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.

  Any advice?

    Brian

------- <blane@aa.net> -------------------- <http://www.aa.net/~blane> -------
  Embedded Systems Programmer, EET Student, Interactive Fiction author (RSN!)
==============  11 99 3D DB 63 4D 0B 22  15 DC 5A 12 71 DE EE 36  ============

Right now, the only solution I know of is to use cookies for browsers that
support them, and do all the MD5-ing yourself. That excludes some browsers,
but you can support those in the totally insecure manner.

On Tue, 9 Apr 1996, Brian C. Lane wrote:

> 
>   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?
> 
>   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.
> 
>   Any advice?
> 
>     Brian
> 
> ------- <blane@aa.net> -------------------- <http://www.aa.net/~blane> -------
>   Embedded Systems Programmer, EET Student, Interactive Fiction author (RSN!)
> ==============  11 99 3D DB 63 4D 0B 22  15 DC 5A 12 71 DE EE 36  ============
> 

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Jeremey Barrett
Senior Software Engineer			jeremey@forequest.com 
The ForeQuest Company       			http://www.forequest.com/

   "less is more."
		-- Mies van de Rohe.

   Ken Thompson has an automobile which he helped design.  Unlike most
   automobiles, it has neither speedometer, nor gas gage, nor any of the
   numerous idiot lights which plague the modern driver.  Rather, if the
   driver makes any mistake, a giant "?" lights up in the center of the
   dashboard.  "The experienced driver", he says, "will usually know
   what's wrong."

		-- 'fortune` output

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?


>   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.
> 
>   Any advice?

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.


-- Jeff

On Tue, 9 Apr 1996 11:58:34 -0400 (EDT), you wrote:

>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?

  It could be implemented thus:

  Server and client have a shared secret. The server sends the time, or
some random # to the client which MD5's this number and the secret, and
sends the result back to the server which then checks is.

  Similar to the APOP command for POP3 that I've never seen implemented.

    Brian


------- <blane@aa.net> -------------------- <http://www.aa.net/~blane> -------
  Embedded Systems Programmer, EET Student, Interactive Fiction author (RSN!)
==============  11 99 3D DB 63 4D 0B 22  15 DC 5A 12 71 DE EE 36  ============

> 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?

	It would require a previous shared secret, but wouldn't the
following protocol work (pardon my ASCII diagram):

	Q - Shared secret; Both server and client know this
	R - Random challenge;  Server sends in clear to client wanting
		to be authenticated.

	Server			Client
1)				Request auth
2)	Send R 
3)				Send back MD5( R, Q )
4)	Compare recieved value
	to computed value	

	Granted this straight off the cuff, and you can't securely
change Q via this protocol (unless you store previous MD5(R,Q)'s and
use that as the next Q (i.e. Q_n+1 = MD5(R,Q_n))).  Once someone gets
MD5 in Java done, you could send an applet that would handle the
protocol client side.

---
Fletch                                                     __`'/|
fletch@ain.bls.com  "Lisa, in this house we obey the       \ o.O'    ______
404 713-0414(w)      Laws of Thermodynamics!" H. Simpson   =(___)= -| Ack. |
404 315-7264(h) PGP Print: 8D8736A8FC59B2E6 8E675B341E378E43  U      ------