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