Re: adduser web page

On Thu, 6 Feb 1997, Koen Holtman wrote:

> Kevin J. Dyer:
> [...]
> >This thread about allowing users to change their passwords via CGI/ Applets
> >can go on forever.  I would like to hear from the community about the
> >possiblity
> >of expanding the 4xx codes in HTTP/1.1 to include the following:
> >
> >	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

Received on Thursday, 6 February 1997 13:01:23 UTC