Security – Sent mail/login log for roundcube webmail

First, DON'T capitulate. He is not only an idiot but DANGEROUSLY wrong. In fact, releasing this information would violate the PCI standard (which is what I'm assuming the audit is for since it's a payment processor) along with every other standard out there and just plain common sense. It would also expose your company to all sorts of liabilities.

The next thing I would do is send an email to your boss saying he needs to get corporate counsel involved to determine the legal exposure the company would be facing by proceeding with this action.

This last bit is up to you, but I would contact VISA with this information and get his PCI auditor status pulled.

Being confronted with the very same issue, I did a few ours of Google-Foo to get to the root of the issue: As Gabriel assumed correcty in his answer, it's not the fault of Roundcube – but of the way the password is stored and the encryption works.

Few obvious basics

When talking about CRAM-MD5, MD5, or CRYPT, we're talking about one-way-encryption: A hash is generated. We cannot do that the other way around, deriving the clear-text password from the hash is (apart from brute-forcing) impossible and not realistic for any login-procedure. So with the password stored using one of these hashes, we can only validate it when having it plain-text – which is why setting $rcmail_config['imap_auth_type'] = 'PLAIN' in the roundcube configuration "solves" this.

Options

1. Stick with PLAIN/LOGIN:
   • fine with Roundcube and IMAP on the same server, as long as users connect with HTTPS
   • fine with access from mail clients, as long as the connection is secured (IMAPS/POP3S/SMTPS)
   • a security hole with unencrypted traffic
2. Store the passwords plain-text
   • all kind of auth mechanisms can be used, which is a pro
   • having all your users' passwords plain-text in a file/database is an absolute no-go
3. Store the passwords using CRAM-MD5
   • gives you at least CRAM-MD5, which most clients support
   • still leaves the option of using PLAIN/LOGIN
   • must be supported by your administrative tools
     • some of them might need to revert to 3rd party tools for encryption (e.g. PostfixAdmin uses /usr/sbin/doveadm pw), which makes the clear-text password appear shortly in the process list each time it is invoked
   • other 3rd party tools (plugins/addons etc.) might be an issue

I'm still struggling which path to go – with only #2 definitely ruled-out (I don't want to make presents to potential hackers ;)