[Dovecot] Can't get apop to work.
Hi Folks,
I'm fairly new to linux so this message may reflect that.
dovecot info (running on CentOS 5.0):
protocols: pop3s listen: ssl_cert_file: /etc/pki/dovecot/certs/dovecot.pem ssl_key_file: /etc/pki/dovecot/private/dovecot.pem login_dir: /usr/local/var/run/dovecot/login login_executable: /usr/local/libexec/dovecot/pop3-login mail_executable: /usr/local/libexec/dovecot/pop3 mail_plugin_dir: /usr/local/lib/dovecot/pop3 pop3_uidl_format: %v.%u auth default: debug: yes debug_passwords: yes passdb: driver: pam userdb: driver: passwd
If I select apop as one of the allowed protocols (in order to avoid having to use ssl) I get this error message in the mail log :
"APOP mechanism can't be supported with given passdbs"
I tried fiddling with PAM by adding an /etc/pam.d/apop file with these contents :
auth required pam_unix.so nullok account required pam_unix.so
makes no difference, in anycase as much reading as I;ve done to understand PAM I still have not much clue: the docs are quite obscure.
My /etc/pam.d/dovecot file looks like this :
#%PAM-1.0 auth required pam_nologin.so auth include system-auth account include system-auth session include system-auth
At this point I seem to be out of options. I've been through the docs, and trawled the internet.
Anyone know what I'm doing wrong?
Thanks,
Greg
Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now.
Greg Lorriman, on 2/7/2008 12:32 AM, said the following:
Hi Folks,
I'm fairly new to linux so this message may reflect that.
dovecot info (running on CentOS 5.0):
As with any software issues, you should always provide basic info for everything, not just platform - like, in this case, dovecot version & FULL dovecot -n output
Also, you didn't say if this is a new installation or if you're migrating from something.
protocols: pop3s listen: ssl_cert_file: /etc/pki/dovecot/certs/dovecot.pem ssl_key_file: /etc/pki/dovecot/private/dovecot.pem login_dir: /usr/local/var/run/dovecot/login login_executable: /usr/local/libexec/dovecot/pop3-login mail_executable: /usr/local/libexec/dovecot/pop3 mail_plugin_dir: /usr/local/lib/dovecot/pop3 pop3_uidl_format: %v.%u
Looks like you're using an old version... you'll need to upgrade. The new default format for POP3 is:
pop3_uidl_format = %08Xu%08Xv
Have you even read the wiki? I think thats where you need to start...
http://wiki.dovecot.org/FrontPage
--
Best regards,
Charles
On Wed, 2008-02-06 at 21:32 -0800, Greg Lorriman wrote:
If I select apop as one of the allowed protocols (in order to avoid having to use ssl) I get this error message in the mail log :
"APOP mechanism can't be supported with given passdbs"
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 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.
Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now.
Greg Lorriman, on 2/7/2008 8:20 AM, said the following:
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.
You still haven't provided concrete details of your system (dovecot version, and/or dovecot -n output)...
Read this page, and search on 'apop' - maybe it helps...
http://wiki.dovecot.org/MainConfig
--
Best regards,
Charles
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
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>
participants (5)
-
Bill Cole
-
Charles Marcus
-
Greg Lorriman
-
mouss
-
Timo Sirainen