[4398] in WWW Security List Archive
Re: adduser web page
daemon@ATHENA.MIT.EDU (Kevin J. Dyer)
Thu Feb 13 11:22:15 1997
Date: Thu, 13 Feb 1997 07:24:57 -0500
From: "Kevin J. Dyer" <kjd4951@aries1.draper.com>
In-reply-to: dreams never end <jna@retina.net>
<"Re: adduser web page"@mb2.draper.com> (Feb 7, 5:57am)
To: dreams never end <jna@retina.net>, Koen Holtman <koen@win.tue.nl>
Cc: kdyer@draper.com, www-security@ns2.rutgers.edu, www-talk@w3.org
Reply-to: kdyer@draper.com
Errors-To: owner-www-security@ns2.rutgers.edu
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]
=============================================================================
