Re: [qmailtoaster] Re: Can I disable CRAM-MD5 authentication for submission service?
On Wed, 11 Sep 2013 15:07:31 +0200, Johannes Weberhofer wrote:
Eric,
this line in the spec will remove CRAM-MD5 completely:
%{__perl} -pi -e s|\#define CRAM_MD5||g qmail-smtpd.c
Johannes
In the .spec file included with qmail-toaster-1.03-1.3.22.src.rpm there is
already something that indicates that CRAM-MD5 is being removed, however the
action line is attempting to remove #define AUTHCRAM which doesn't exist
anywhere in qmail-smtpd.c, before or after patches are applied:
# Remove CRAM-MD5 because qmail-remote-auth doesn't like it
#---
%{__perl} -pi -e s|\#define AUTHCRAM||g qmail-smtpd.c
If, as it appears, the .spec is set to remove CRAM-MD5 by default, it isn't
working. The line Johannes suggested earlier *does* work correctly to remove
CRAM-MD5. Can someone comment on this?
Thanks!
--
Quinn Comendant
Strangecode, LLC
http://www.strangecode.com/
+1 530 624 4410 mobile
+1 530 636 2633 office
@qc and @strangecode
-
To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com
For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
Re: [qmailtoaster] Re: Can I disable CRAM-MD5 authentication for submission service?
Am 13.09.2013 04:30, schrieb Quinn Comendant:
On Wed, 11 Sep 2013 15:07:31 +0200, Johannes Weberhofer wrote:
this line in the spec will remove CRAM-MD5 completely:
%{__perl} -pi -e s|\#define CRAM_MD5||g qmail-smtpd.c
I'd like to do this as well to remove the dependence on pw_clear_passwd. It's
really this easy? And the clients that were using CRAM MD5 before will then use
the alternative available option(s) during the smtp/submission transaction?
I look forward to seeing this as a full howto up on the wiki. ;)
Quinn
I'd recommend to disable plaintext-passworts in vpopmail, too (see configure)
and to disable CRAM-MD5 as authentication method in dovecot.
Where possible you should force using SSL or TLS connections.
Johannes
--
Johannes Weberhofer
Weberhofer GmbH, Austria, Vienna
-
To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com
For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
[qmailtoaster] Re: Can I disable CRAM-MD5 authentication for submission service?
On 09/13/2013 07:59 AM, Johannes Weberhofer wrote:
Am 13.09.2013 04:30, schrieb Quinn Comendant:
On Wed, 11 Sep 2013 15:07:31 +0200, Johannes Weberhofer wrote:
this line in the spec will remove CRAM-MD5 completely:
%{__perl} -pi -e s|\#define CRAM_MD5||g qmail-smtpd.c
I'd like to do this as well to remove the dependence on
pw_clear_passwd. It's really this easy? And the clients that were
using CRAM MD5 before will then use the alternative available
option(s) during the smtp/submission transaction?
I look forward to seeing this as a full howto up on the wiki. ;)
Quinn
I'd recommend to disable plaintext-passworts in vpopmail, too (see
configure) and to disable CRAM-MD5 as authentication method in dovecot.
Where possible you should force using SSL or TLS connections.
Johannes
I agree.
I would try to minimize the impact on users before shutting this down on
the server though. You can see in /var/log/maillog which authentication
methods are being used. You can grep this to see who is using cram-md5,
then notify them that this authentication method will no longer be
available effective the date of your choosing. Including instructions
regarding how to change their configuration would also be appropriate. I
would also recommend a reminder notification shortly before the change
to those who hadn't changed their client(s) yet.
Of course, you're the admin, and can handle things to your liking. :)
--
-Eric 'shubes'
-
To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com
For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
Re: [qmailtoaster] Re: Can I disable CRAM-MD5 authentication for submission service?
Hi, On Fri, Sep 13, 2013 at 4:33 AM, Eric Shubert e...@shubes.net wrote: I know it seems cumbersome, but it's really not all that bad. Administrators should be able to change passwords, but not see in any way what they currently are. What's the point of encrypting a password if someone can decrypt it? That's not the way encryption works. It's a one-way street (which is why it works). Who's watching the watchers? - Enemy Of The State (movie, IIRC) ;) Ok I get this. But what about my other suggestion: An another option would be to make the postmaster password a master password that could be used to access all accounts in that domain. ? Best, Peter
[qmailtoaster] Re: Can I disable CRAM-MD5 authentication for submission service?
On 09/13/2013 11:36 AM, Peter Peltonen wrote: Hi, On Fri, Sep 13, 2013 at 4:33 AM, Eric Shubert e...@shubes.net mailto:e...@shubes.net wrote: I know it seems cumbersome, but it's really not all that bad. Administrators should be able to change passwords, but not see in any way what they currently are. What's the point of encrypting a password if someone can decrypt it? That's not the way encryption works. It's a one-way street (which is why it works). Who's watching the watchers? - Enemy Of The State (movie, IIRC) ;) Ok I get this. But what about my other suggestion: An another option would be to make the postmaster password a master password that could be used to access all accounts in that domain. ? Best, Peter I think that's the case with qmailadmin to some extent. The postmaster can control all accounts in the domain. What would be the purpose of allowing the postmaster to read/delete people's emails? The QMT administrator can of course grep through emails and look at them with less or whatever tools are available there. I would like to see an option where even this would not be possible. I'm not in favor of using the mbox format though (in case someone's wondering). The objective here is to ensure that emails are as private as possible, and the user is entirely in control as much as practical. -- -Eric 'shubes' - To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
Re: [qmailtoaster] Re: Can I disable CRAM-MD5 authentication for submission service?
On 9/13/2013 3:18 PM, Eric Shubert wrote: I think that's the case with qmailadmin to some extent. The postmaster can control all accounts in the domain. What would be the purpose of allowing the postmaster to read/delete people's emails? The QMT administrator can of course grep through emails and look at them with less or whatever tools are available there. I would like to see an option where even this would not be possible. I'm not in favor of using the mbox format though (in case someone's wondering). The objective here is to ensure that emails are as private as possible, and the user is entirely in control as much as practical. OK, so you want to secure email messages in a Maildir (or mbox, for that matter) format so that even root cannot read them? Good luck with that! :-) (You might be able to do this with SELinux, but even then, root can dynamically turn off enforcement, so you're outta luck!) The only way the *I* know of to protect data against root access is to drum roll _*turn off the system and destroy the hard drives.*_ Otherwise, the root user can accomplish whatever s/he has the heart, mind, desire, and skills to accomplish on that system... which is why a rootkitted *nix system is such a dangerous animal! (When I did security consulting, I told clients who had been rooted to not even TRY to re-secure such a system... build a NEW system just copy over the data.) Quick aside: Its also why I insist on having a /home filesystem that I can put ALL user accessible storage on -- and then set the NODEV NOSUID flags on the mount! Mind you -- not being *able *to access data is not the same thing as not being able to EASILY access that data! Thus, when my users inquire, I tell them that: a) Yes, I am the root user on the mail server, so I CAN see EVERYTHING! But... b) I am not a snoop, and my privacy policy states that I WON'T actually read any emails or other documents that belong to them unless specifically authorized to do so. They have to trust me NOT to read their mail with a mail reader, open a word document with a document reader, etc... while at the same time giving me the ability to read the file with various other programs -- like virus scanners, backups, and other system admin activities. If you don't trust your system admin, move to another system (or other system admin!) Dan McAllister -- PLEASE TAKE NOTE OF OUR NEW ADDRESS === IT4SOHO, LLC 33 - 4th Street N, Suite 211 St. Petersburg, FL 33701-3806 CALL TOLL FREE: 877-IT4SOHO 877-484-7646 Phone 727-647-7646 Local 727-490-4394 Fax We have support plans for QMail!
[qmailtoaster] Re: Can I disable CRAM-MD5 authentication for submission service?
I don't see how a master password is significantly easier than having the admin change/set the user's password, do the testing, then letting the user change their password when the admin's done. That being said, if someone writes the code for this in such a way that it can be made an option, I'd gladly include it. I don't see any reason not to. At this point though, vpopmail's authentication doesn't provide such a mechanism that I'm aware of. -- -Eric 'shubes' On 09/13/2013 01:05 PM, Peter Peltonen wrote: Hi, On Fri, Sep 13, 2013 at 10:18 PM, Eric Shubert e...@shubes.net mailto:e...@shubes.net wrote: What would be the purpose of allowing the postmaster to read/delete people's emails? Sometiems one needs to login to user's account and verify some config settings from webmail, for example. Easiest way to debug if an account is working, is to sent a user a msg, login to webmail and check if it is there. Or to send a msg from the webmail after a complaint I cannot login to webmail or My account is not working etc. The QMT administrator can of course grep through emails and look at them with less or whatever tools are available there. I would like to see an option where even this would not be possible. I'm not in favor of using the mbox format though (in case someone's wondering). As root can access the emails anyway, I do not see why postmaster couldn't login to user's account with a master password -- It's the same kind of situation as that root can access users homedirs and use sudo to login with user's account if needed to test something? I understand your concern for privacy. My view is is that sysadmins are not that different from medical doctors: the customers/patients trust you with their private and sensitive affairs, and it is your responsibility to keep the information only to yourself. Best, Peter - To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
[qmailtoaster] Re: Can I disable CRAM-MD5 authentication for submission service?
On 09/13/2013 01:37 PM, Dan McAllister wrote: On 9/13/2013 3:18 PM, Eric Shubert wrote: I think that's the case with qmailadmin to some extent. The postmaster can control all accounts in the domain. What would be the purpose of allowing the postmaster to read/delete people's emails? The QMT administrator can of course grep through emails and look at them with less or whatever tools are available there. I would like to see an option where even this would not be possible. I'm not in favor of using the mbox format though (in case someone's wondering). The objective here is to ensure that emails are as private as possible, and the user is entirely in control as much as practical. OK, so you want to secure email messages in a Maildir (or mbox, for that matter) format so that even root cannot read them? Good luck with that! :-) (You might be able to do this with SELinux, but even then, root can dynamically turn off enforcement, so you're outta luck!) The only way the *I* know of to protect data against root access is to drum roll _*turn off the system and destroy the hard drives.*_ Otherwise, the root user can accomplish whatever s/he has the heart, mind, desire, and skills to accomplish on that system... which is why a rootkitted *nix system is such a dangerous animal! (When I did security consulting, I told clients who had been rooted to not even TRY to re-secure such a system... build a NEW system just copy over the data.) Quick aside: Its also why I insist on having a /home filesystem that I can put ALL user accessible storage on -- and then set the NODEV NOSUID flags on the mount! Mind you -- not being *able *to access data is not the same thing as not being able to EASILY access that data! Thus, when my users inquire, I tell them that: a) Yes, I am the root user on the mail server, so I CAN see EVERYTHING! But... b) I am not a snoop, and my privacy policy states that I WON'T actually read any emails or other documents that belong to them unless specifically authorized to do so. They have to trust me NOT to read their mail with a mail reader, open a word document with a document reader, etc... while at the same time giving me the ability to read the file with various other programs -- like virus scanners, backups, and other system admin activities. If you don't trust your system admin, move to another system (or other system admin!) Dan McAllister -- Yeah Dan, we know. I wouldn't mind implementing a method though where messages were stored with encryption that's controlled by each user. Maybe I should write an RFC for that. -- -Eric 'shubes' - To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
Re: [qmailtoaster] Re: Can I disable CRAM-MD5 authentication for submission service?
Suggested options (not sure how to do it -- hurt my back and not thinking 100% this morning): - Users are the only ones who should be using SMTP AUTH, and they should NOT be using port 25 when they do it... so the SMTP daemon on port 25 should NOT ALLOW SMTP AUTH at all - Its up to you whether you support SUBMISSION connections on port 587 with or without SSL, but in my case I REQUIRE SSL on both ports 587 and 465 (several mail clients will specifically look for 465 with SSL before even trying 587). Of course, this means that I either pay for a publicly signed SSL certificate, or make my users import my self-signed certificate. Once you're connecting on ports 587 or 465 over SSL, the AUTH method is less important -- it's all encrypted in the SSL connection. Just my thoughts... Dan McAllister On 9/10/2013 9:59 AM, Eric Shubert wrote: On 09/10/2013 02:34 AM, Johannes Weberhofer wrote: Dear all! For security reasons I have disabled the storage of vpopmail's plain-text passwords. Upon connection the qmail-server still responds with 250-server.test.com - Welcome to Qmail Toaster Ver. 1.03.5 SMTP Server 250-STARTTLS 250-PIPELINING 250-8BITMIME 250-SIZE 20971520 250 AUTH LOGIN PLAIN CRAM-MD5 Qmail's implementation of cram-md5 is implemented in a way, that the plain-text password is required [1] for CRAM-MD5 authentication. My problem is, that some clients are sending the CRAM-MD5 response, but Qmail is not able to process it correctly. Unfortunately I have not found a way to turn this feature off. Does someone know, how to? Best regards, Johannes [1] http://en.wikipedia.org/wiki/CRAM-MD5 You're one step ahead of me, Johannes. :) I had planned to do so by having spamdyke handle authentication. The current version doesn't implement this quite rightly though, but it'll be fixed in the soon to be released version. In the meantime, check for qmail config options in the .spec file. There might be a ./configure option for turning cram-md5 off. I don't know off hand, but I would expect so. Either that or vpopmail. I don't recall off hand how qmail makes the determination of which auth methods are available. Please let me know how you make out with this. Thanks! P.S. Just to be clear, plain-text passwords are required for any implementation of cram-md5, not just qmail's. That's a weakness which is inherent in the protocol. -- PLEASE TAKE NOTE OF OUR NEW ADDRESS === IT4SOHO, LLC 33 - 4th Street N, Suite 211 St. Petersburg, FL 33701-3806 CALL TOLL FREE: 877-IT4SOHO 877-484-7646 Phone 727-647-7646 Local 727-490-4394 Fax We have support plans for QMail! - To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
Re: [qmailtoaster] Re: Can I disable CRAM-MD5 authentication for submission service?
Eric, Why wouldn't it be possible to keep the plaintext password field in the vpopmail database, but protect it? I would think you could compile vpopmail to keep the cleartext passwords, but then create an additional user in the DB (an admin user) and restrict rights to view that field to the admin user. (NOTE: You still have to have write permission to that field from the vpopmail user so that updates/changes can be recorded). Just an idea... Dan McAllister On 9/10/2013 12:39 PM, Eric Shubert wrote: On 09/10/2013 08:06 AM, Johannes Weberhofer wrote: P.S. Just to be clear, plain-text passwords are required for any implementation of cram-md5, not just qmail's. That's a weakness which is inherent in the protocol. The wiki page says, that some (dovecot) implementation stores a intermediate step of HMAC, so I guess there is anoter way to do that, too. I sit corrected. :) http://wiki2.dovecot.org/HowTo/CRAM-MD5 Again, I don't know off hand. I suspect that it's vpopmail which needs the clear text for it's implementation of cram-md5. If vpopmail can be configured/changed in such a way that it uses a password hash instead of clear text for cram-md5, that would seem to be ideal. I'm not adverse to keeping cram-md5, but I think the storage of plain text passwords needs to go bye-bye. I know of several potential users we've lost due to this, and it's simply a bad practice. I know there are some users who have expressed a preference to keep plain text passwords. It would be nice to have an option whereby they could continue this insecure practice, and I will try to provide this option if it doesn't take too much work. I think the 'stock' QMT should not be configured in this manner though, and someone else may need to do the development to make this possible if I can't come up with an easy way to accommodate it. -- PLEASE TAKE NOTE OF OUR NEW ADDRESS === IT4SOHO, LLC 33 - 4th Street N, Suite 211 St. Petersburg, FL 33701-3806 CALL TOLL FREE: 877-IT4SOHO 877-484-7646 Phone 727-647-7646 Local 727-490-4394 Fax We have support plans for QMail! - To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
Re: [qmailtoaster] Re: Can I disable CRAM-MD5 authentication for submission service?
Am 12.09.2013 14:21, schrieb Dan McAllister: Eric, Why wouldn't it be possible to keep the plaintext password field in the vpopmail database, but protect it? I would think you could compile vpopmail to keep the cleartext passwords, but then create an additional user in the DB (an admin user) and restrict rights to view that field to the admin user. (NOTE: You still have to have write permission to that field from the vpopmail user so that updates/changes can be recorded). Just an idea... Dan McAllister Dan, the problem is easily described: when someone gets access to the database (content, dumps, backups) this person will have full access to the plain passwords; as many users re-use the passwords that's a very critical issue. Best regards, Johannes -- Johannes Weberhofer Weberhofer GmbH, Austria, Vienna - To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
Re: [qmailtoaster] Re: Can I disable CRAM-MD5 authentication for submission service?
Hi, My 2 cents: On Thu, Sep 12, 2013 at 7:22 PM, Johannes Weberhofer jweberho...@weberhofer.at wrote: Am 12.09.2013 14:21, schrieb Dan McAllister: Eric, Why wouldn't it be possible to keep the plaintext password field in the vpopmail database, but protect it? I would think you could compile vpopmail to keep the cleartext passwords, but then create an additional user in the DB (an admin user) and restrict rights to view that field to the admin user. (NOTE: You still have to have write permission to that field from the vpopmail user so that updates/changes can be recorded). Just an idea... Dan McAllister Dan, the problem is easily described: when someone gets access to the database (content, dumps, backups) this person will have full access to the plain passwords; as many users re-use the passwords that's a very critical issue. Would it be possible to encrypt the passwords in the db but at the same time also offer a tool to print out the password in clear text (decrypt it) if one knows a master password? An another option would be to make the postmaster password a master password that could be used to access all accounts in that domain. I can imagine many occasions for small service providers that they need to access their customers' webmails to check some preferences or to debug if their email is working / not working. Changing the client's password every time to do this feels cumbersome... Regards, Peter
[qmailtoaster] Re: Can I disable CRAM-MD5 authentication for submission service?
On 09/12/2013 11:12 AM, Peter Peltonen wrote: Hi, My 2 cents: On Thu, Sep 12, 2013 at 7:22 PM, Johannes Weberhofer jweberho...@weberhofer.at mailto:jweberho...@weberhofer.at wrote: Am 12.09.2013 14:21, schrieb Dan McAllister: Eric, Why wouldn't it be possible to keep the plaintext password field in the vpopmail database, but protect it? I would think you could compile vpopmail to keep the cleartext passwords, but then create an additional user in the DB (an admin user) and restrict rights to view that field to the admin user. (NOTE: You still have to have write permission to that field from the vpopmail user so that updates/changes can be recorded). Just an idea... Dan McAllister Dan, the problem is easily described: when someone gets access to the database (content, dumps, backups) this person will have full access to the plain passwords; as many users re-use the passwords that's a very critical issue. Would it be possible to encrypt the passwords in the db but at the same time also offer a tool to print out the password in clear text (decrypt it) if one knows a master password? An another option would be to make the postmaster password a master password that could be used to access all accounts in that domain. I can imagine many occasions for small service providers that they need to access their customers' webmails to check some preferences or to debug if their email is working / not working. Changing the client's password every time to do this feels cumbersome... Regards, Peter I know it seems cumbersome, but it's really not all that bad. Administrators should be able to change passwords, but not see in any way what they currently are. What's the point of encrypting a password if someone can decrypt it? That's not the way encryption works. It's a one-way street (which is why it works). Who's watching the watchers? - Enemy Of The State (movie, IIRC) ;) -- -Eric 'shubes' - To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
[qmailtoaster] Re: Can I disable CRAM-MD5 authentication for submission service?
On 09/12/2013 05:16 AM, Dan McAllister wrote: Suggested options (not sure how to do it -- hurt my back and not thinking 100% this morning): - Users are the only ones who should be using SMTP AUTH, and they should NOT be using port 25 when they do it... so the SMTP daemon on port 25 should NOT ALLOW SMTP AUTH at all I agree that submissions SHOULD NOT use port 25, and I'd like to have all client submissions use port 587. I just don't think it's practical to deny authentications on port 25 though. I think forcing clients to use port 587 would create a lot of helpdesk issues, and to what benefit? I think all it would accomplish would be to tick off some users, unless you could somehow get them all converted to use port 587 ahead of implementing the restriction. In any case, I think QMT is going to need to allow for configuring port 25 to accept authentication (submissions). However, once spamdyke is handling authentication (running on both ports 25 and 587), it should be trivial to configure it to prohibit authentication on port 25. I'll mention this to Sam, to see how this might work. - Its up to you whether you support SUBMISSION connections on port 587 with or without SSL, but in my case I REQUIRE SSL on both ports 587 and 465 (several mail clients will specifically look for 465 with SSL before even trying 587). Of course, this means that I either pay for a publicly signed SSL certificate, or make my users import my self-signed certificate. I agree entirely with this. The stock QMT will support SMTPS(465) in a future release (although it's not exactly compliant with RFCs, many clients and servers have implemented it). I hope to use spamdyke to enforce encrypted authentication as well (deny plain text authorization), the same as dovecot presently does. Of course on port 465, this wouldn't be necessary since the entire session is encrypted. Once you're connecting on ports 587 or 465 over SSL, the AUTH method is less important -- it's all encrypted in the SSL connection. 10-4. Just my thoughts... Thanks! -- -Eric 'shubes' - To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
[qmailtoaster] Re: Can I disable CRAM-MD5 authentication for submission service?
On 09/12/2013 06:48 PM, Eric Shubert wrote: I'll mention this to Sam, to see how this might work. Good thing I checked the documentation before I posted: http://www.spamdyke.org/documentation/README.html#SMTP_AUTH The none value will effectively turn off smtp-auth, disabling submissions on port 25 (except for domains in rcpthosts). -- -Eric 'shubes' - To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
Re: [qmailtoaster] Re: Can I disable CRAM-MD5 authentication for submission service?
On Wed, 11 Sep 2013 15:07:31 +0200, Johannes Weberhofer wrote:
this line in the spec will remove CRAM-MD5 completely:
%{__perl} -pi -e s|\#define CRAM_MD5||g qmail-smtpd.c
I'd like to do this as well to remove the dependence on pw_clear_passwd. It's
really this easy? And the clients that were using CRAM MD5 before will then use
the alternative available option(s) during the smtp/submission transaction?
I look forward to seeing this as a full howto up on the wiki. ;)
Quinn
-
To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com
For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
Re: [qmailtoaster] Re: Can I disable CRAM-MD5 authentication for submission service?
Am 10.09.2013 17:30, schrieb Bharath Chari:
In the meantime, check for qmail config options in the .spec file. There might
be a ./configure option for turning cram-md5 off. I don't know off hand, but I
would expect so. Either that or vpopmail. I don't recall off hand how qmail
makes the determination of which auth methods are available.
Please let me know how you make out
with this.
Eric,
this line in the spec will remove CRAM-MD5 completely:
%{__perl} -pi -e s|\#define CRAM_MD5||g qmail-smtpd.c
Johannes
--
Johannes Weberhofer
Weberhofer GmbH, Austria, Vienna
-
To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com
For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
[qmailtoaster] Re: Can I disable CRAM-MD5 authentication for submission service?
On 09/11/2013 06:07 AM, Johannes Weberhofer wrote:
Am 10.09.2013 17:30, schrieb Bharath Chari:
In the meantime, check for qmail config options in the .spec file.
There might be a ./configure option for turning cram-md5 off. I don't
know off hand, but I would expect so. Either that or vpopmail. I don't
recall off hand how qmail makes the determination of which auth
methods are available.
Please let me know how you make out
with this.
Eric,
this line in the spec will remove CRAM-MD5 completely:
%{__perl} -pi -e s|\#define CRAM_MD5||g qmail-smtpd.c
Johannes
Sweet, Johannes. It should be easy to make that conditional with a build
flag of some sort.
We still need to examine vpopmail though to see if we can retain
CRAM_MD5 with no clear text passwords. Would anyone like to delve into that?
Thanks.
--
-Eric 'shubes'
-
To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com
For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
[qmailtoaster] Re: Can I disable CRAM-MD5 authentication for submission service?
On 09/10/2013 02:34 AM, Johannes Weberhofer wrote: Dear all! For security reasons I have disabled the storage of vpopmail's plain-text passwords. Upon connection the qmail-server still responds with 250-server.test.com - Welcome to Qmail Toaster Ver. 1.03.5 SMTP Server 250-STARTTLS 250-PIPELINING 250-8BITMIME 250-SIZE 20971520 250 AUTH LOGIN PLAIN CRAM-MD5 Qmail's implementation of cram-md5 is implemented in a way, that the plain-text password is required [1] for CRAM-MD5 authentication. My problem is, that some clients are sending the CRAM-MD5 response, but Qmail is not able to process it correctly. Unfortunately I have not found a way to turn this feature off. Does someone know, how to? Best regards, Johannes [1] http://en.wikipedia.org/wiki/CRAM-MD5 You're one step ahead of me, Johannes. :) I had planned to do so by having spamdyke handle authentication. The current version doesn't implement this quite rightly though, but it'll be fixed in the soon to be released version. In the meantime, check for qmail config options in the .spec file. There might be a ./configure option for turning cram-md5 off. I don't know off hand, but I would expect so. Either that or vpopmail. I don't recall off hand how qmail makes the determination of which auth methods are available. Please let me know how you make out with this. Thanks! P.S. Just to be clear, plain-text passwords are required for any implementation of cram-md5, not just qmail's. That's a weakness which is inherent in the protocol. -- -Eric 'shubes' - To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
Re: [qmailtoaster] Re: Can I disable CRAM-MD5 authentication for submission service?
Am 10.09.2013 15:59, schrieb Eric Shubert: On 09/10/2013 02:34 AM, Johannes Weberhofer wrote: Dear all! For security reasons I have disabled the storage of vpopmail's plain-text passwords. Upon connection the qmail-server still responds with 250-server.test.com - Welcome to Qmail Toaster Ver. 1.03.5 SMTP Server 250-STARTTLS 250-PIPELINING 250-8BITMIME 250-SIZE 20971520 250 AUTH LOGIN PLAIN CRAM-MD5 Qmail's implementation of cram-md5 is implemented in a way, that the plain-text password is required [1] for CRAM-MD5 authentication. My problem is, that some clients are sending the CRAM-MD5 response, but Qmail is not able to process it correctly. Unfortunately I have not found a way to turn this feature off. Does someone know, how to? Best regards, Johannes [1] http://en.wikipedia.org/wiki/CRAM-MD5 You're one step ahead of me, Johannes. :) I had planned to do so by having spamdyke handle authentication. The current version doesn't implement this quite rightly though, but it'll be fixed in the soon to be released version. In the meantime, check for qmail config options in the .spec file. There might be a ./configure option for turning cram-md5 off. I don't know off hand, but I would expect so. Either that or vpopmail. I don't recall off hand how qmail makes the determination of which auth methods are available. Please let me know how you make out with this. Thanks! I'll let you know (if). It's a matter of time... P.S. Just to be clear, plain-text passwords are required for any implementation of cram-md5, not just qmail's. That's a weakness which is inherent in the protocol. The wiki page says, that some (dovecot) implementation stores a intermediate step of HMAC, so I guess there is anoter way to do that, too. Best regards, Johannes -- Johannes Weberhofer Weberhofer GmbH, Austria, Vienna - To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
Re: [qmailtoaster] Re: Can I disable CRAM-MD5 authentication for submission service?
There's some work i had done last year. See this message. My memory is a bit foggy on the specifics right now but please do try it out. Not on a production server of course!!! Don't go by the version numbering - it is not a branch that is part of the official release. http://permalink.gmane.org/gmane.mail.qmail.toaster.devel/999 Bharath Johannes Weberhofer jweberho...@weberhofer.at wrote: Am 10.09.2013 15:59, schrieb Eric Shubert: On 09/10/2013 02:34 AM, Johannes Weberhofer wrote: Dear all! For security reasons I have disabled the storage of vpopmail's plain-text passwords. Upon connection the qmail-server still responds with 250-server.test.com - Welcome to Qmail Toaster Ver. 1.03.5 SMTP Server 250-STARTTLS 250-PIPELINING 250-8BITMIME 250-SIZE 20971520 250 AUTH LOGIN PLAIN CRAM-MD5 Qmail's implementation of cram-md5 is implemented in a way, that the plain-text password is required [1] for CRAM-MD5 authentication. My problem is, that some clients are sending the CRAM-MD5 response, but Qmail is not able to process it correctly. Unfortunately I have not found a way to turn this feature off. Does someone know, how to? Best regards, Johannes [1] http://en.wikipedia.org/wiki/CRAM-MD5 You're one step ahead of me, Johannes. :) I had planned to do so by having spamdyke handle authentication. The current version doesn't implement this quite rightly though, but it'll be fixed in the soon to be released version. In the meantime, check for qmail config options in the .spec file. There might be a ./configure option for turning cram-md5 off. I don't know off hand, but I would expect so. Either that or vpopmail. I don't recall off hand how qmail makes the determination of which auth methods are available. Please let me know how you make out with this. Thanks! I'll let you know (if). It's a matter of time... P.S. Just to be clear, plain-text passwords are required for any implementation of cram-md5, not just qmail's. That's a weakness which is inherent in the protocol. The wiki page says, that some (dovecot) implementation stores a intermediate step of HMAC, so I guess there is anoter way to do that, too. Best regards, Johannes -- Johannes Weberhofer Weberhofer GmbH, Austria, Vienna - To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com -- Sent from my Android phone with K-9 Mail. Please excuse my brevity.
[qmailtoaster] Re: Can I disable CRAM-MD5 authentication for submission service?
On 09/10/2013 08:06 AM, Johannes Weberhofer wrote: P.S. Just to be clear, plain-text passwords are required for any implementation of cram-md5, not just qmail's. That's a weakness which is inherent in the protocol. The wiki page says, that some (dovecot) implementation stores a intermediate step of HMAC, so I guess there is anoter way to do that, too. I sit corrected. :) http://wiki2.dovecot.org/HowTo/CRAM-MD5 Again, I don't know off hand. I suspect that it's vpopmail which needs the clear text for it's implementation of cram-md5. If vpopmail can be configured/changed in such a way that it uses a password hash instead of clear text for cram-md5, that would seem to be ideal. I'm not adverse to keeping cram-md5, but I think the storage of plain text passwords needs to go bye-bye. I know of several potential users we've lost due to this, and it's simply a bad practice. I know there are some users who have expressed a preference to keep plain text passwords. It would be nice to have an option whereby they could continue this insecure practice, and I will try to provide this option if it doesn't take too much work. I think the 'stock' QMT should not be configured in this manner though, and someone else may need to do the development to make this possible if I can't come up with an easy way to accommodate it. -- -Eric 'shubes' - To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
