How to Configure Roundcube/Dovecot for Effective 2-Factor Authentication

dovecotimaproundcubetwo-factortwo-factor-authentication

There are several Roundcube plugins that provide two-factor authentication. However, the issue I now see is that I can still simply log in via IMAP/SMTP, without 2-FA (obviously). 2-FA is (effectively) useless here.

I thought I could solve this problem by introducing application-specific passwords and doing something similar as Google is also doing with their 2-FA and applications that don't support it.

Now I thought I could automatically generate an app-specific password for Roundcube for each user, which is different to the one used to login to the Roundcube web interface. The result would be that the user can still have their own password + 2-FA for logging in to Roundcube but the same password can't be used for IMAP/SMTP directly. However, I cannot seem to find a way to configure Roundcube to use a different IMAP password to the one used to log into the web interface.

Both Roundcube and Dovecot are running on the same machine.

Am I missing something here? Is what I am doing sensible? This seems like a problem which could be solvable in a more elegant manner than what I'm attempting, so am I missing something there? All I really want is 2-FA authentication wherever possible and application-specific passwords everywhere else.

Thank you!

Best Answer

After trying around some more I found two reasonable solutions/workarounds, at least for this simple case.

Option 1: using allow_nets. Dovecot allows for various extra fields to be returned by the passdb, including 'allow_nets' (http://wiki2.dovecot.org/PasswordDatabase/ExtraFields/AllowNets). By setting allow_nets to 127.0.0.1 for the password that is to be used by Roundcube any login attempts from other sources will fail. If Roundcube is on a different machine the IP will need to be adjusted, obviously. Problems with this approach are non-static IP addresses and if users have other non 2-FA ways to log in via e.g. a proxy running on the same machine as Roundcube.

Option 2: Using CheckPassword to write a custom authentication script. Using the checkpassword driver (http://wiki2.dovecot.org/AuthDatabase/CheckPassword) for the passdb allows for a custom authentication script to be written. You can check the client IP in there or do something entirely different. Possible issues here are performance and you might need some extra configuration for user lookups, as checkpassword doesn't support user lookups. Also, the problem of verifying how the user is actually trying to log in remains.

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

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
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
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 ;)

Dovecot Certificate Authentication

The Dovecot wiki seems to have an error, or maybe the name of the ssl_username_from_cert setting has changed. On my Ubuntu host with Dovecot 2.2.9, in /etc/dovecot/conf.d/10-auth.conf, I have:

# Take the username from client's SSL certificate, using 
# X509_NAME_get_text_by_NID() which returns the subject's DN's
# CommonName. 
#auth_ssl_username_from_cert = no

So it seems that you need to replace ssl_username_from_cert by auth_ssl_username_from_cert, and the wiki needs to be corrected.

Best Answer

Related Solutions

Postgresql – RoundCube login to local IMAP server failing

Few obvious basics

Options

Dovecot Certificate Authentication

Related Topic