[Dovecot] Can't get apop to work.

[mouss]

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>