ive.org> <[EMAIL PROTECTED]> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <[EMAIL PROTECTED]>; from [EMAIL PROTECTED] on Tue, Feb 12, 2002 at 10:33:15PM -0800
Well, by NOT offering that, getting passwords is as simple as sniffing the net. And that's just easier to do. No, at this point a dedicated POP server can be made Secure Enough (I'd never say Unbreakable). This means, of course, only administrative access to the machine and doing security Best Practices. Furthermore, the tokens should not be stored in plain text by the program somewhere but rather encrypted in a way that the popper server can get the plain text out of it. Most of the SASL methods I've looked at do this. Evil hacker breaks onto the machine, gets a file of shared keys that is a binary mush. S/he then must break that or find the keys used from the crypto binary. Frankly, once on the machine, wiring in a sniffer is less effort. APOP is enough for ISPs. Esp when the alternative for serving 500 concurrent connections means rolling out several machines to handle the TLS negotiation. KPOP anyone? Quoting Ted Cabeen ([EMAIL PROTECTED]): > In message <[EMAIL PROTECTED]>, Chuck Yerkes writes: > >APOP and TLS meet SOME of the same gaols, but they are not > >close to the same and have different uses. > > > >APOP users a safe password for authentication. The rest of > >the session is clear text. Computationally, it's light-weight > >and easy to scale. > > > I'm not sure I'd want to offer TLS if I were an basic ISP. > >APOP, on the other hand, costs me almost nothing to offer. > > Except for the fact that if you do offer APOP, you have to keep clear-text > passwords on the server. That doesn't seem worth the risk to me. > > --Ted
