[Dovecot] Can't get apop to work.

[Bill Cole]

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 at scconsult.com