dovecot - May 2013 - Looking for a good way to manage passwords for CRAM-MD5

I prefer not to use clear text passwords, even over an encrypted
connection.  With IMAP, the only such mechanism with widespread client
support is CRAM-MD5 (please correct my if I'm wrong... I'd love to be
corrected here...).

On the dovecot 2 wiki, the only way I've found to implement CRAM-MD5
support, is to use a passwd-like file:
 http://wiki2.dovecot.org/HowTo/CRAM-MD5

I am running a small IMAP server used by my family.

As long as I was the single user on the IMAPd, manually managing the
passwd file as doable (if a bit cumbersome).

With 2-5 users, I'm looking for a more elegant solution.

Does anyone have a similar situation, and a solution they would like to
share (config/HOWTO)?

Here are the possibilities that comes to mind:
 1. Create a web interface to change the password (does anyone know of a
    ready-made solution for this that they could recommend?)
 2. Convince PAM to update the dovecot HMAC-MD5 password file as well as
    the regular system password file (my dovecot runs on a debian stable
    "wheezy" system.  In theory this should be possible, but it is
very
    hard to find documentation on what PAM modules exist, and how to
    write a new one, and if it is possible to chain modules in PAM,
    ie. use one module to update-this-passwd-file and then use a
    different module to update a different passwd file)
 3. Use LDAP, which I think can also support CRAM-MD5 when using
    password lookups
     http://wiki2.dovecot.org/AuthDatabase/LDAP/PasswordLookups
    (learning how to set up LDAP is something I have avoided for years,
    because it looks awfully complex and time consuming)

I haven't looked into using databases, SQL, or key-value store, because
they seem like a more cumbersome way to do the same thing as passwd
files. 

But I am aware that this assumption could be wrong.  It could e.g. be
easier to make the web interface idea work with a database manager, than
messing around with setuid bits to safely update a passwd file owned and
touchable only by the dovecot user.

Thanks for any and all responses!


- Steinar

On 5/12/2013 4:17 AM, Steinar Bang wrote:
> I prefer not to use clear text passwords, even over an encrypted
> connection.
Why?  Enforce the encrypted link by not allowing unencrypted
connections.  The simplest is iptables to block ports 110 and 143, while
allowing 993 and 995.

As long as the underlying SSL/TLS connection utilizes strong mechanisms,
everything in the connection is secure, including passwords.  CRAM adds
complexity, without adding security if the connection is already secure.
 Just make sure that you have something like fail2ban to block or slow
down dictionary and brute force attacks and make sure you use strong
passwords.

While it seems that adding encryption on top of encryption adds more
security, the problem is in how the algorithms interact.  There is a
reason there is no Double-DES.  DES has 56 bits of entropy.  You would
assume Double-DES had 112 and Triple-DES had 168 bits.  However, due to
complex and non-obvious interactions between the different layers,
Double-DES only adds one bit, effectively, making 57 bits of entropy.
Triple-DES adds another 56 for a total of 113.  Quadruple-DES would only
add another single bit, for a total of 114 - with a required key of 224
bits.  Not a good use of key material, plus it is slow.

Also note that MD5, the basis for CRAM-MD5, is considered weak and no
longer recommended.  Thus, if you face an attacker that is sophisticated
enough to crack the SSL / TLS connection, they very likely will have
little problem with the CRAM-MD5 mechanism.


> Does anyone have a similar situation, and a solution they would like to
> share (config/HOWTO)?
> 
> Here are the possibilities that comes to mind:
>  1. Create a web interface to change the password (does anyone know of a
>     ready-made solution for this that they could recommend?)
Many webmail systems have plugins that allow the user to change their
password.  Look into Squirrelmail or Roundcube.  You have your choice,
depending on how your passwords are stored.

You can use the poppassd plugin for both of these, but note IT IS NOT
SECURE, so it should *only* be used to change passwords over the
loopback interface (127.0.0.1).  This has been the easiest to set up in
my experience, but the added complexity of securing the daemon and
domain socket may not be worth it.

There are also plugins that interface with PAM, which I find the second
easiest to set up.

There are plugins that allow you to call some glue logic (Perl, Python,
shell scripts, etc) which enables you to interface to pretty much any
method (SQL, LDAP, shadow files, etc) you have chosen to save passwords
- that is, as long as you are capable of writing the glue logic yourself.

> But I am aware that this assumption could be wrong.  It could e.g. be
> easier to make the web interface idea work with a database manager, than
> messing around with setuid bits to safely update a passwd file owned and
> touchable only by the dovecot user.
Ouch!  Do not do this!  Use the system provided command line tools for
changing passwords, or better yet, the PAM API.

Actually a database or LDAP is the best way to go.  Shadow files are
used for more than just email authentication.  Adding users to the
shadow files who are just supposed to get email can create all sorts of
security holes.  Not something you want to do, seeing as how you are
trying to improve security.


My recommendation:

Install a webmail system and password update plugin.  Disable port 80
and only allow access via port 443.


Block ports 110 and 143 and only allow access to email via ports 993 and
995.  You can access your webmail server via the same hostname as the
mail server.  Example: mailhost.mydomain.com can be access from a web
browser as https://mailhost.mydomain.com.  This way, you can use the
same certificate for the mail server and webmail.  I usually recommend
separating services on physically different hardware, due to the use of
a shared certificate, this is an exception.  HOWEVER, only run the
webmail system on your web server, do not host any other sites on this
machine.  The more sites you add the more chance one of them will have a
vulnerability that could be used to compromise the entire machine.
Think a house of cards crashing down.


Avoid using a self signed certificate.  Get a properly signed
certificate for your server.  CheapSSLS.com has them for less then $10.


Unless you have experience with CRAM-MD5, I would stay away from it.
The problem with security, and why it is so difficult, is that you
cannot prove something to be secure, only that it is insecure.  One tiny
mistake and the security of your system is compromised.  Unless you have
experience with CRAM-MD5, the extra complexity means you have a higher
chance of making a mistake that compromises your security.  Stick with a
simple authentication method that is easy to set up.  Less chance for
mistakes.

Dem

Steinar Bang wrote:
> it is very hard to find documentation on what PAM modules exist,
> and how to write a new one, and if it is possible to chain modules in PAM
The PAM documentation can be found at:
http://www.linux-pam.org/Linux-PAM-html/

The Linux-PAM System Administrators' Guide
http://www.linux-pam.org/Linux-PAM-html/Linux-PAM_SAG.html
contains a list of standard modules.

The Linux-PAM Application Developers' Guide
http://www.linux-pam.org/Linux-PAM-html/Linux-PAM_ADG.html
explains how to develop modules.

Regards
Daniel
-- 
https://plus.google.com/103021802792276734820