W3C home > Mailing lists > Public > www-talk@w3.org > March to April 1996

Re: custom authentication functions

From: Marc Salomon <marc@matahari.ckm.ucsf.edu>
Date: Wed, 27 Mar 1996 11:49:56 -0800
Message-Id: <9603271149.ZM16004@matahari.ckm.ucsf.edu>
To: www-talk@w3.org

Some issues that need to be addressed with www authentication seem to cross
paths here.  First, there needs to be a scheme where users can authenticate on
a web server using account information valid for other services (such as telnet
or ppp) on that machine.   It would be nice to share big passwd databases
between the web and existing systems, but there seem to be differences in
crypt()s (according to the folks at NCSA) across platforms, both client and

Second, there needs to be some way for a CGI process (or any server-side
application) to have access to protocol-level authentication date so that it
can take steps such as passing those data to external servers (Z39.50, namely)
to gain authorization there.  On some dedicated systems functioning as www
servers, random users reading environment variables are not really a serious
security issue.  Doing this through forms is hoky.

In the end, this is a server implementation issue, and paternalistic concerns
about security risks in certain configurations should not obviate informed
consent. On the toy platforms this is probably less of a problem than on unix

Application-level authentication checking can be done fairly securely in a
modular server, but the standard (for now) is CGI.  Also, concerns about random
users viewing env's of other processes with a full ps listing is important but
not always applicable.  Its even more of a danger in certain configurations
than snarfing authentication over the wire, because there is no effort involved
in running ps as there is in sniffing data packets.

Lastly, not all authentication schemes are based on the login/passwd model.
Some only have a single cryptic password.  It would be cool to specify the
number of authentication terms required for a custom scheme so that users are
not confused by being prompted with boxes they should ignore.


// Marc Salomon - Software Engineer - Innovative Software Systems Group     \\ 
\\ Library and Center for Knowledge Management - UC, San Francisco          // 
// phone :  415.476.9541 - e-mail : marc@ckm.ucsf.edu - fax: 415.476.4653   \\
Received on Wednesday, 27 March 1996 14:50:16 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:32:58 UTC