I think the real issue in this case is if a 3rd party can listen to the connection. If the TCP stack handles loopback internally, then it is virtually impossible for a 3rd party to sniff the connection (and thus get the users password). If the clear text passwords go over the wire, it's trivial to get the users password.
In the localhost case, while there might well be local exploits, you still need to get the users password to be able to connect to their mail store so local access per-se isn't the security hole. Larry Osterman -----Original Message----- From: Matti Aarnio [mailto:[EMAIL PROTECTED]] Sent: Wednesday, November 27, 2002 9:46 AM To: Mark Crispin Cc: [EMAIL PROTECTED] Subject: Re: allow plaintext password if localhost connection? On Wed, Nov 27, 2002 at 08:58:38AM -0800, Mark Crispin wrote: ... > The question is whether or not it is safe to exempt localhost > connections. Since localhost does not go out over the wire and hence > is internal to the local system, it arguably is not within the IETF > domain to declare compliance. I am comfortable with that argument; I > am not completely sure whether we can assume that localhost > connections are a secure path. In general terms that boils down to "how secure is local system". There are a lot more ways to threat system security from within the box, than over the network. You might even consider "local" not only loopback, but any connection where getpeername() and getsockname() returned addresses are same (port-numbers will vary, of course.) -- /Matti Aarnio <[EMAIL PROTECTED]>
