Postfix + Dovecot with MySQL backend: md5-hashed passwords and CRAM-MD5 auth

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,

1. 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 list¹
2. I'm possibly introducing a new dependency (the very same tool)
3. 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}

Solution 1:

As I got no answers, I've experimented myself and finally did the switch – which went smoothly. The advantage is, as initially stated, having at least CRAM-MD5 available for authentication on unencrypted transport, should encrypted transport not be available (yes, that happens) – plus making the migration from the old server smoother for those already using CRAM-MD5 there. Apart from that, I didn't see any side-effects yet – though it might take a while for those to turn up :)

So for those interested, here are the steps to perform:

• Dovecot: change default_pass_scheme from MD5-CRYPT to CRAM-MD5 in your /etc/dovecot/dovecot-mysql.conf (or the corresponding file you're using), then add cram-md5 to auth_mechanisms in /etc/dovecot/dovecot.conf
• Postfix: In my case, Postfix uses Dovecot for auth via SASL (smtpd_sasl_type=dovecot) – so nothing to do here
• PostfixAdmin:
  • First login to the PostfixAdmin WebIF and stay logged in – or you won't be able to do so after the config changes :)
  • changes in config.inc.php: $CONF['encrypt'] = 'md5crypt'; must be changed to $CONF['encrypt'] = 'dovecot:CRAM-MD5';. Also check $CONF['dovecotpw'] = "/usr/sbin/doveadm pw"; – e.g. on Debian Wheezy, doveadm resides in /usr/bin and thus requires this setting to be adjusted
  • Now go to the PostfixAdmin WebIf (where you're still logged in) and update the user passwords: navigate to "Virtual lists", scroll to "Mailboxes", hit the "edit" link for each mailbox, and there store the "new password" (this means you either have to know their passwords – or set "some" password and have them update it later. No way to "convert" the existing password, to my knowledge).
    Repeat the same for the Admins via "Admin list" – or they/you won't be able to login again
• Restart mail services. Basically, it should suffice to restart Dovecot and, maybe, Postfix.

Done. Now you can verify if everything is still working. In my case it was: Roundcube was still able to auth PLAIN – and a remote client now was able to use CRAM-MD5. Case solved, for me.