The obvious answer is to use transport-level encryption services, such as IPSec (IP Security) or other VPN (virtual private network) technologies, but these mainly protect against packet captures outside the firewall. Whether or not we like to admit it, most attacks originate inside the firewall. To be effective, network protocols should use some form of challenge/response protocol that never sends the actual password across the wire. Until point-to-point IPSec encryption becomes a reality, guarding your users' passwords should be a serious concern. The vendor community has recognized this problem and has presented various solutions for non-clear-text POP and IMAP authentication.
When we tested non-plain text authentication protocols for use in POP and IMAP services at our Real-World Labs® in San Mateo, Calif., we found that many products work exactly as billed, but a lack of standardization makes each a single-vendor solution.
In terms of interoperability, SSL POP and IMAP offer the best support, with client support from Microsoft Corp. and Netscape Communications Corp. Qualcomm's implementations of APOP (Authentication POP) and KPOP (Kerberos POP) can be convincing in the right environments, but like Microsoft's NTLM (NT LAN Man) via SASL (Simple Authentication Security Layer) authentication scheme, both offer limited cross-vendor support. Finally, SASL gives us a glimpse into the future of IP authentication and it's being rolled into LDAP and other protocols.
APOP
POP in RFC 1460 defines an MD5-based challenge/ response authentication algorithm dubbed APOP. A simple example of challenge/response authentication is that it adds a challenge string to the normal POP server. The client responds with a hash of that challenge and the user's password (see "Challenge/ Response Authentication," at www.networkcomputing. com/1018/1018ws2side1.html). If the client's response matches the server's own hash, the user is authenticated. The hash isn't reversible, so the user's password isn't compromised when sent over the network.
Despite APOP's appearance in the RFC, Qualcomm is the only vendor to support it. We were surprised and disappointed to find that Microsoft's Outlook Express and Outlook2000 POP3 support does not include APOP authentication. But if you're willing to stay inside Qualcomm's product line, APOP is an excellent choice for strong POP authentication. We tested APOP using Qualcomm's Eudora Pro 4.1 and qpopper, Qualcomm's Unix POP daemon.
Enabling APOP is easy. APOP is added as a configuration option when the qpopper POP3 daemon is compiled (like much Unix software, qpopper is distributed in source-code form). From then on, the administrator must define a separate APOP authentication database using the popauth command and must add a password for each user. After that, users connecting to the server must use APOP-capable clients.
Be aware that APOP must hash the user's password in combination with the server's challenge, so the POP server must maintain a separate authentication database for APOP users. Although qpopper provides the popauth utility for database administration (it also lets users reset their own APOP passwords), it means users must manage yet another password.