Postfix and Dovecot – How to Use MySQL Backend with 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}