Re: A modest proposal for access authentication
Marc VanHeyningen <mvanheyn@cs.indiana.edu>
From: Marc VanHeyningen <mvanheyn@cs.indiana.edu>
To: www-talk@nxoc01.cern.ch
Subject: Re: A modest proposal for access authentication
In-reply-to: Your message of "Thu, 16 Sep 1993 12:39:34 PDT."
<93Sep16.123937pdt.2794@golden.parc.xerox.com>
Date: Thu, 16 Sep 1993 15:17:20 -0500
Message-id: <11883.748210640@prickly.cs.indiana.edu>
Sender: mvanheyn@cs.indiana.edu
Status: RO
Thus wrote: Larry Masinter
>The modest proposal is: use FTP.
>
>a) add a new kind of URL: FTPU://host/path
> this URL is like FTP: except that it assumes that the user will
>supply a user name and password, i.e., not anonymous access
Using cleartext passwords is not security, it's the illusion of
security. There's very little authentication, no message integrity
checking, no disclosure protection, and no non-repudiation of origin.
>Well, yes, FTP is slower than HTTP, but by the time you do all this
>authorization and stuff, maybe it isn't that much slower, and you can
>cache FTP connections which have logged in, etc. Besides, web servers
>already have FTP code in them, the only thing you have to do is keep
>track of username/password pairs for specific hosts.
That "only thing" is very hard to do, and won't scale.
>You're not inventing any new security scheme, so you're unlikely to
>get into trouble, like gopher did, of compromising the security of a
>site by introducing a new, incompatible security mechanism. FTP
>already has access control, and separate access control for read and
>write, so you don't have to build a new ACL mechanism.
Here I'll agree in principle; we should invent as little new stuff as
possible. But there are other constraints; we should be consistent
with existing tendencies in the protocol, keep the protocol
request-response, and have something that will scale adequately.
(Something that can be used in the U.S. would also be nice.)
- Marc
--
Marc VanHeyningen mvanheyn@cs.indiana.edu MIME, RIPEM & HTTP spoken here