Re: [Dovecot] Looking for a good way to manage passwords for CRAM-MD5
Steinar Bang s...@dod.no: Professa Dementia profe...@dementianati.com: 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. [snip! PAM modules in perl and python] However, I'm not really all that familiar with Python, so it may just be simpler to write a module in C or C++. Here are three articles that look like they might be useful to accomplish this. http://www.linuxdevcenter.com/pub/a/linux/2002/05/02/pam_modules.html http://www.linuxdevcenter.com/pub/a/linux/2002/05/23/pam_modules.html http://www.linuxdevcenter.com/pub/a/linux/2002/05/30/pam_modules.html (The articles are 11 years old, though, so they may be a bit out of date) The articles weren't all that helpful really. They missed the most important part: a simple example showing all of the parts that take place in a module. But anyway, here is a PAM module, written in ANSI C/POSIX, that will hook into a password change in PAM, and use the password change to update a CRAM-MD5 coded version of the same password, in the file /etc/dovecot/cram-md5.pwd (currently hardcoded). https://github.com/steinarb/pam_dovecotmd5pwd Some PAM module basics: 1. #define the roles your module will have. My module only hooked into password changes, so I only have the line: #define PAM_SM_PASSWORD 2. Include the pam_modules.h file (Note: this must be _after_ the #defines that defines the roles 3. Implement the method(s) for the roles you you have #define'd (I have only one) 4. Inside #ifdef PAM_STATIC define a struct that will hold the name of the module, and function pointers to all the implemented methods. This struct is used if all of the PAM modules are linked statically into a single binary Hm... here was actually a good example of a module that hooks into all roles and return ignore on all of them: http://www.rkeene.org/projects/info/wiki/222
Re: [Dovecot] Looking for a good way to manage passwords for CRAM-MD5
Daniel Parthey daniel.part...@informatik.tu-chemnitz.de: The PAM documentation can be found at: http://www.linux-pam.org/Linux-PAM-html/ This one I have already visited, if the link colour in the browser is to be belived. However it didn't make much of an impression at the time. Now, however, after actually writing a PAM module, what that document says, makes sens to me... so there is probably something about that document that needs improvement. My suggestion for improvement would be: start with a simple example, and explain out from that. First how, then later you can explain why and what. The Linux-PAM System Administrators' Guide http://www.linux-pam.org/Linux-PAM-html/Linux-PAM_SAG.html contains a list of standard modules. Many interesting modules here. Wonder why this one never showed up in my sources. The Linux-PAM Application Developers' Guide http://www.linux-pam.org/Linux-PAM-html/Linux-PAM_ADG.html explains how to develop modules. This one I hadn't visited before. But again: starting with a simple example and explaining ot from that would probably be a good idea. Here was a good module: http://www.rkeene.org/projects/info/wiki/222 In retrospect, after writing this module https://github.com/steinarb/pam_dovecotmd5pwd it was suprisingly easy to get the module up and running.
Re: [Dovecot] Looking for a good way to manage passwords for CRAM-MD5
On Sun, May 12, 2013 at 05:40:10AM -0700, Professa Dementia wrote: 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. I don't understand this advice. Why would someone who is apparently interested in heightened transport security restrict himself to the older generation SSL v.2, which was long ago superceded by TLS v.1? http://en.wikipedia.org/wiki/Transport_Layer_Security#SSL_1.0.2C_2.0_and_3.0 http://wiki2.dovecot.org/SSL Quoting from the latter page: Some admins want to require SSL/TLS, but don't realize that this is also possible with STARTTLS (Dovecot has disable_plaintext_auth=yes and ssl=required settings). -- http://rob0.nodns4.us/ -- system administration and consulting Offlist GMX mail is seen only if /dev/rob0 is in the Subject:
Re: [Dovecot] Looking for a good way to manage passwords for CRAM-MD5
On 5/14/2013 12:39 PM, /dev/rob0 wrote: On Sun, May 12, 2013 at 05:40:10AM -0700, Professa Dementia wrote: 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. I don't understand this advice. Why would someone who is apparently interested in heightened transport security restrict himself to the older generation SSL v.2, which was long ago superceded by TLS v.1? Forcing the connection to 993/995 does not imply SSLv2. TLSv1.[012] is still negotiated. There is no decrease in security. http://en.wikipedia.org/wiki/Transport_Layer_Security#SSL_1.0.2C_2.0_and_3.0 http://wiki2.dovecot.org/SSL Quoting from the latter page: Some admins want to require SSL/TLS, but don't realize that this is also possible with STARTTLS (Dovecot has disable_plaintext_auth=yes and ssl=required settings). It's not unreasonable to disable the plaintext ports to minimize the possibility of a fat-fingered accident. -- Noel Jones
Re: [Dovecot] Looking for a good way to manage passwords for CRAM-MD5
On Tue, 14 May 2013 12:39:34 -0500 /dev/rob0 r...@gmx.co.uk wrote: On Sun, May 12, 2013 at 05:40:10AM -0700, Professa Dementia wrote: 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. I don't understand this advice. Why would someone who is apparently interested in heightened transport security restrict himself to the older generation SSL v.2, which was long ago superceded by TLS v.1? http://en.wikipedia.org/wiki/Transport_Layer_Security#SSL_1.0.2C_2.0_and_3.0 http://wiki2.dovecot.org/SSL Quoting from the latter page: Some admins want to require SSL/TLS, but don't realize that this is also possible with STARTTLS (Dovecot has disable_plaintext_auth=yes and ssl=required settings). SSL vs STARTTLS in this context has nothing to do with SSL/TLS versions (and available ciphers). The thing is that SSL and STARTTLS in this context represent different mechanisms by which you can initiate an SSL/TLS handshake. The SSL method means you connect to port 993 and start a handshake immediately (similar to HTTPS). The STARTTLS method means you're connecting through port 143, using plain-text communications at first, until you send a STARTTLS command to server. When a STARTTLS has been issued, both client and server proceed with an SSL/TLS handshake the same way as if the client had connected to port 993. It's unfortunately poor selection of terminology, but everyone is using it, therefore introducing a bit of confusion with people that are into PKI that much :) In effect, in both cases (if the software is built and configured correctly) you'll be using TLSv1.0 or higher. The thing is that if you connect to port 993, and Dovecot is configured to use SSL there straight away, if the client starts sending IMAP commands in plain-text, the server will cut connection due to invalid SSL/TLS handshake. When using plain-text port 143, the client may attempt to send out username/password even though the server requires TLS (well, the client shouldn't do this, since server should signal the client what are its capabilities, but you never know how bad the client implementation is). I hope this description helps a bit :) Best regards P.S. I think there's even been one discussion regarding this relatively recently on Dovecot mailing lists. -- Branko Majic Jabber: bra...@majic.rs Please use only Free formats when sending attachments to me. Бранко Мајић Џабер: bra...@majic.rs Молим вас да додатке шаљете искључиво у слободним форматима. signature.asc Description: PGP signature
Re: [Dovecot] Looking for a good way to manage passwords for CRAM-MD5
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
Re: [Dovecot] Looking for a good way to manage passwords for CRAM-MD5
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
Re: [Dovecot] Looking for a good way to manage passwords for CRAM-MD5
On 05/12/2013 08:40 AM, Professa Dementia wrote: Avoid using a self signed certificate. Get a properly signed certificate for your server. CheapSSLS.com has them for less then $10. Look also at https://www.startssl.com/
Re: [Dovecot] Looking for a good way to manage passwords for CRAM-MD5
On 5/12/2013 6:18 AM, Gedalya wrote: On 05/12/2013 08:40 AM, Professa Dementia wrote: Avoid using a self signed certificate. Get a properly signed certificate for your server. CheapSSLS.com has them for less than $10. Look also at https://www.startssl.com/ StartSSL is good - and free. I have used them in the past. The reason I did not list them was that I find their interface a bit clunky and odd to navigate. Also, in order to get a free cert, it has to be for non-commercial use. They tend to turn down certs for hosts that do not begin with www and you have no recourse to convince them that your mailhost.xyz.com cert is for personal use. But, give them a try first. For free, there is nothing to lose. Dem
Re: [Dovecot] Looking for a good way to manage passwords for CRAM-MD5
Professa Dementia profe...@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,
Re: [Dovecot] Looking for a good way to manage passwords for CRAM-MD5
Professa Dementia skrev den 2013-05-12 14:40: 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. why not disable 110, 143 in dovecot ?, its waste leas in firewalls to not provide service on blocked ips :) As long as the underlying SSL/TLS connection utilizes strong mechanisms, everything in the connection is secure, including passwords. plain passwords have no problem in treverse in ssl/tls, but it might still be possible to store unencrypted cookies on webmail, so this question is still valid, but this is not a dovecot problem to resolve more like to remove so bad writed webmail client first CRAM adds complexity, without adding security if the connection is already secure. yes, avoid pam auth, use unix auth if its unix mailboxes, and setup eg postfixadmin for virtual users, follow readme in there and it mostly done with all possible powers of dovecot / postfix, (postfixadmin does not really need postfix but an sql mta that can make the same querys in sql) 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. seen in ssl/tls ports ? -- senders that put my email into body content will deliver it to my own trashcan, so if you like to get reply, dont do it
Re: [Dovecot] Looking for a good way to manage passwords for CRAM-MD5
Steinar Bang s...@dod.no: Professa Dementia profe...@dementianati.com: 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 There are claims in Authen::PAM that it can be used to write PAM modules in perl, but I have yet to find an example showing how. It is available as a debian package: http://packages.debian.org/wheezy/libauthen-pam-perl (however, while that package contains an .so, it looks like that .so is meant for inclusion into perl, rather than being an .so meant for inclusion into PAM, that would start a perl interpreter and run a script) The pam_python module is more obviously what I was looking for (ie. an .so residing in /lib/security that runs a python script) http://packages.debian.org/wheezy/libpam-python However, I'm not really all that familiar with Python, so it may just be simpler to write a module in C or C++. Here are three articles that look like they might be useful to accomplish this. http://www.linuxdevcenter.com/pub/a/linux/2002/05/02/pam_modules.html http://www.linuxdevcenter.com/pub/a/linux/2002/05/23/pam_modules.html http://www.linuxdevcenter.com/pub/a/linux/2002/05/30/pam_modules.html (The articles are 11 years old, though, so they may be a bit out of date)
