Professa Dementia professa@dementianati.com:
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.
Well, yes. But the CRAM in CRAM-MD5 means that the password itself never crosses the wire, and that is the thing I'm trying to avoid.
Of course the flip side of that is that you need to have a (more or less) clear text storage of the password itself on either side. Still... that feels better somehow, to passing it over the wire.
[snip!]
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.
"poppassd" was a useful google search word. There is a debian package for poppasd, and also a package called poppassd-cgi.
The poppassd of debian uses PAM, so that gives me a easy web based password change solution for basic auth.
There are also plugins that interface with PAM, which I find the second easiest to set up.
Yes. Using PAM is the default for debian dovecot, so if I decide to go with basic auth things get easy.
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.
Thanks for the tip. That let me narrow down the googling to find this: https://metacpan.org/module/Authen::PAM::Module
[snip! Changing passwd files from CGI scripts]
Ouch! Do not do this! Use the system provided command line tools for changing passwords, or better yet, the PAM API.
Yes, but both of those only allow for basic auth.
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.
Quite. However I had no intention of touching /etc/passwd or /etc/shadow. Just the HMAC-MD5 passwd file used by dovecot.
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.
Yes... however, this is an immediate family email server, so it is neither a high profile, nor a high traffic site. :-) (cost is also a factor)
Avoid using a self signed certificate. Get a properly signed certificate for your server. CheapSSLS.com has them for less then $10.
I have a Cacert.org signed certificate. Works fine on a debian client (has the CA cert built-in), and the CA cert can be installed for Windows MUAs like Opera and Thunderbird.
But it's not possible to install the CA cert on iOS versions >4 (rumor has it the capability was present in late betas of iOS 5, but diseappeared from the final release).
Also, installing a CA cert was a real pain on Android last time I looked into it. I haven't looked recently.
Unless you have experience with CRAM-MD5, I would stay away from it.
I have been using CRAM-MD5 first on cyrus, later on dovecot, from 2000/2001 or thereabouts.
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.
True. Thanks for your input!
There are many ways forward that are easy, if I go for basic auth. Very few, and very crooked, ways if I decide to stick with CRAM-MD5.