Bill Cole wrote:
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.
regarding APOP vulnerabilty:
http://fse2007.uni.lu/slides/rump/apop.pdf
see also:
http://www.securityfocus.com/archive/1/464477/30/0/threaded
In particular:
<citation>
APOP should be considered broken in the man-in-the-middle setting.
User should be encouraged to switch to another authentication
mechanism, such as CRAM-MD5 (or use TLS...).
</citation>
