At 5:20 AM -0800 2/7/08, Greg Lorriman wrote:
I tried fiddling with PAM by adding an /etc/pam.d/apop file with these contents :
It's impossible to support anything but plaintext authentication with PAM. See http://wiki.dovecot.org/Authentication/Mechanisms and http://wiki.dovecot.org/Authentication/PasswordSchemes
I'm not overly worried about PAM; I just want to get APOP working. But the wiki doesn't give me even the faintest idea, keeping in mind that I am relatively new to linux. The same applies to all the other authentication schemes. It only tells me how to change the conf file, which doesn't appear to be enough.
Obviously I am missing something here. But I don't know what.
The way APOP works requires the POP3 server to have the user's unencrypted password. There is no way around that. This means that if you want to support APOP with Dovecot, you need to use a passdb configuration that offers access to the password in plaintext. In particular that requires using a passdb driver other than 'pam' because PAM by design does not provide client programs like Dovecot with access to plaintext passwords, and it would be an unusual system where PAM itself has access to passwords in any form that can readily be translated into plaintext. The referenced wiki pages and the pages they link to explain this in detail, but they do require you to read carefully, absorb the meaning, and synthesize your own solution. There is no cookbook for getting APOP to work. It always requires a password database of some sort that is independent from the operating system's standard mechanism, i.e. PAM or /etc/{passwd,shadow}, because non-toy OS-level authentication systems never store passwords in any directly recoverable form but only in testable forms, i.e. one-way hashes.
On a general conceptual level, any password storage scheme that protects passwords in storage limits you to using only plaintext authentication mechanisms plus at most one compatible non-plaintext mechanism. For example, CRAM-MD5 password storage only allows you to support CRAM-MD5 authentication or plaintext authentication. The logical design of APOP precludes the use of any minimally secure (i.e. one-way hash) password storage scheme because the authentication check is based on a hash of the plaintext password and username with a one-time-use token.
It is probably a better idea to reconsider why you want APOP at all. All APOP provides is protection from someone sniffing out the password on the wire. That was a larger risk when APOP was devised than it really is today due to the fact that switches have largely supplanted hubs and a more complete solution is available with SSL/TLS support. APOP doesn't protect mail itself from being sniffed, and comes at the cost of requiring the server to store plaintext passwords, which in most modern cases is a risk of similar magnitude to the risk of having plaintext passwords on the wire. A far better option if your users are not locked into archaic clients is to only offer access over encrypted (SSL/TLS) sessions, and allow plaintext (PLAIN and LOGIN) authentication mechanisms. That would allow you to use PAM rather than a free-standing password database with plaintext passwords that you only use for APOP because nothing else that claims to be secure in the modern world would ever use such a database.
-- Bill Cole bill@scconsult.com