My question
What are the risks of switching from MD5 to CRAM-MD5 passwords in the database, especially considering the following, and how to approach that for an existing installation (provided I know the plain text passwords)?
With (switching to) CRAM-MD5,
- for encryption/verification, PostfixAdmin has to revert to an external tool (
doveadm pw
) on user creation and for password changes, so the clear-text password would at least shortly appear in the process list1 - I'm possibly introducing a new dependency (the very same tool)
- Uncertain whether other (3rd party) tools can deal with that
Item 2 might not be a big deal, as I don't plan to replace Dovecot (and even if, it has well documented migration paths IMHO). Item 3 is not a big deal yet (as I'm not aware of such tools). Behind the scenes there's also SASL which, IIRC, does this part of its job with the help of Dovecot again (e.g. smtpd_sasl_type=dovecot
in the Postfix config). But it might be I've missed something – be it more trouble, or another option.
Any hints? What would you recommend (apart from a completely different setup)?
TL;DR (background)
I'm in the middle of a setup of a new mail server, using Dovecot, Postfix, PostfixAdmin, Sieve, some additional components – all connected with MySQL as backend (losely following this German tutorial). I've got everything up and running so far, but then noticed it offers only PLAIN and LOGIN for IMAP authentication. Not a big deal for local connections (e.g. the Roundcube web mailer on the same machine) and other "encrypted connections" (HTTPS/IMAPS/POP3S/SMTPS) – but I'm afraid some of the users will use unencrypted connections instead, which I don't want to disable completely (there are situations where those might be needed).
So I've enabled CRAM-MD5 and DIGEST-MD5 in Dovecot – which of course could not work: PostfixAdmin stores the passwords in the database using its internal MD5 procedure, and so Dovecot cannot match them (see my answer here for details). Which basically leaves me with 3 options, one of them not even being such:
- leaving it as-is (with the risks described above)
- switching to plain-text passwords in the database (ouch, no, won't do)
- switching to CRAM-MD5 passwords in the database
Update
From investigating the "participants", here's a comparison of possibilities:
PwdStore MD5 PwdStore CRAM-DM5 Webmail (Roundcube) Client/Server HTTPS only (HTTP requests would be upgraded, so PLAIN = OK) IMAP PLAIN PLAIN / CRAM-MD5 (internal)² SMTP PLAIN PLAIN / CRAM-MD5 (internal)² Native Clients (connecting to Postfix/Dovecot) IMAP³ PLAIN / LOGIN PLAIN / LOGIN / CRAM-MD5 SMTP³ PLAIN / LOGIN PLAIN / LOGIN / CRAM-MD5 POP3³ PLAIN / LOGIN PLAIN / LOGIN / CRAM-MD5 IMAPS PLAIN / LOGIN PLAIN / LOGIN / CRAM-MD5 SMTPS PLAIN / LOGIN PLAIN / LOGIN / CRAM-MD5 POP3S PLAIN / LOGIN PLAIN / LOGIN / CRAM-MD5 PostfixAdmin Create/Update MD5 (internal) CRAM-MD5 (via dovecotadm)⁴
1: I just checked the sources, and found the following in postfixadmin/functions.inc.php
at line 928:
Use proc_open call to avoid safe_mode problems and to prevent showing plain password in process table
So this counter-argument seems to fall.
2: roundcube/program/lib/Roundcube/rcube_imap_generic.php
line 90ff, in function authenticate()
3: PLAIN/LOGIN usually disabled on unencrypted connections
4: Could possibly be re-written using the code from Roundcube, as both are written in PHP – but PostfixAdmin