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

Question

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

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.

Comments

[Izzy]

@masegaloeh As I wrote, that would be fine for me (I know what I'm doing), but I'm afraid some of the users will use unencrypted connections instead, especially the elders who don't know the implications. // Thanks for the link, where this answer somehow sums up parts of my concerns – with the exception that I do not consider storing plain-text passwords but CRAM-MD5 directly (so with PLAIN/LOGIN used, the server converts that first, while otherwise it can compare the hashes directly).

[sebix]

I'm afraid some of the users will use unencrypted connections You are seriously not enforcing encryption for the MDA?!

[Izzy]

@sebix I don't enforce it for local delivery (with the web-mailer running on the same machine). I don't permit unencrypted auth from remote (to protect credentials). I strongly recommend everyone using secure channels (TLS). But not all clients support TLS; I won't reject incoming mail just because of that. Doing it this way, I'll be able to figure who is still using PLAIN/LOGIN w/o TLS (won't work with this setup), get the chance to "explain security" – and still have a chance for cases where TLS might be "impossible".

[sebix]

I don't know of any clients not supporting SMTP. If they exist, I strongly recommend to not support them. Local delivery is usually never secured and always trusted, I talked about submitted mails from outside the secure network.

[Izzy]

@sebix I won't block incoming mail just because it comes in unencrypted (say, from another server for an account on my domains). I however target to have "my users" all using TLS. Most of them are not that "techy" to figure for themselves. I'm pretty sure I'll manage to have their MUAs configured for TLS – but don't want to risk having one of them "sitting in the dark". Once I'm sure they're all "fine", that's another situation. // "I don't know of any clients not supporting SMTP": Sure not. But what has that to do with encryption? SMTP itself is not encrypted (port 25) ;)

[sebix]

Sorry, meant TLS, not SMTP. IMHO as server admin I do have the responsibility to use configure the services so there are no security implications, unencrypted traffic from clients is such a flaw. In case you don't know: you can have different TLS settings for smtpd/25 and submission/587, have a look at bettercrypto.org

[Izzy]

Understood, @sebix. But unless I can be 100% sure no mail gets lost when I close :25, I won't do that. Currently I'm running with a self-signed cert (it's just a few users here, so paying for a cert is a bit overkill – waiting for that Mozilla cert service to open next month), so some "very secure servers" might refuse that.

[sebix]

100% sure no mail gets lost when I close :25 I'm talking about submission/587 (authenticated users submitting mails for relay), not smtpd/25 (oder servers delivering mail). Self-signed certificates are very widely used for mail, nobody verifies them.

[Izzy]

Thanks for that inside, @sebix – didn't know cert checking is that relax with SMTP (though that doesn't change my wanting a "validated" cert, need that for the web service anyway ;). And well, looks like we had a slight misunderstanding: with "unencrypted" I was referring to port 25 of course, not to submission.