Re: adduser web page

On Feb 7,  5:57am, dreams never end wrote:
> Subject: Re: adduser web page
> On Thu, 6 Feb 1997, Koen Holtman wrote:
>
> > Kevin J. Dyer:
> > [...]
[...]
> > >	416  Re-Validation requested
> > >
> > >	The username was accepted but the password was challenged again or
> > >	the sysadmin expired the password, etc.
> > >
> > >	The user agent would display a pop-up requesting two fields.
>
> This is a function that should happen inside of the browser's window. We
> shouldn't be expanding the HTTP spec to support a change in client behaviour.
>
> I'd have to also vote strongly against adding this result code to a server
> because it lends itself to poor security. Depending on how it's implemented,
> you could use the 416 result code to probe for valid account names, and then
> make subsequent attempts to breach the accounts. Look at the model for
> Unix login - You don't know if the password/username are valid until you've
> entered them both, and then you recieve a 'login incorrect' message, which
> is ambiguious. It's best that way.
>
> It's bad enough that the password is sent in the clear for non-ssl
> transactions.
>
> > Do you have in mind that this code should clear the password cache of the
> > user agent, effectively ending the auhenticated session so that the user
can
> > walk away from the (public) web browser?  A code for that would be useful.
>
> That's been a major complaint of mine since Basic Authentication started -
> Once you've cached a password, most of the major browsers don't clear their
> password caches (even in a "Clear Disk/Memory Cache" Request!) There should
> be some way for a site to say "Okay, your cached password isn't any good
> in this realm anymore. Log in again." Perhaps this is where the efforts for
> 416 should be headed.
>
> -john
>-- End of excerpt from dreams never end

My original intent of 416 was to build into the protocol something that
people are recreating time and time again.  I'll agree that we do not want
to overload this protocol, but as you both have said we do need a way to
revoke authentication.  This will start to allow servers to create timed
access windows and hopefully reduce the vulnerabilities.  This brings up
a point that needs further addressing.

	There should be two revocations available to the server.

	1) The user's authentication window has expired and the user must
	   revalidate his/her credentials.  A 416 would revoke the existing
	   cached password and bring up the password requestor.

	2) The users's authentication has been hereby revoked and the user's
	   credentials for this realm should be removed from cache, no further
           connections shall be allowed.

	   I see this being usefull for hidden URL's created on the
	   fly by servers for downloads.

		This could be and extension of a 416, but I think we
		should argue for an addition to the 403 FORBIDDEN
		return code.

Although I did not mention it in my original post Sect 15 of the 1.1 spec
is very much a requirement here.

					Rocks, bottles, stones???


						Thanks,
							Kevin


--
=============================================================================
Kevin J. Dyer					Draper Laboratory  MS 23.
Email: <kdyer@draper.com>		        555 Tech. Sq.
Phone: 617-258-4962				Cambridge, MA 02139
FAX: 617-258-2121
-----------------------------------------------------------------------------
   Anyone who slaps a "this page is best viewed with Browser X" label on a
   Web page appears to be yearning for the bad old days, before the Web,
   when you had very little chance of reading a document written on
   another computer, another word processor, or another network.
                   [Tim Berners-Lee in Technology Review, July 1996]
=============================================================================

Received on Thursday, 13 February 1997 07:30:06 UTC