Re: [suse-security] Plaintext passwords IMAP please!
-- snipped a lot of "I tried..." and "...didn't work" --
Really it's such a simple thing I want to do!
Can anyone help?
This is really not so hard to solve. SuSE's imap-2002 package released with 8.2 and 9.0 has to be explicitly enabled to accept plaintext passwords. Some file in the documentation mentions that. It also warns of the risks. But if all machines using this IMAP server are as you told us behind a firewall, this should be OK. It is easily done by creating a file '/etc/c-client.cf' with the following content: -- I accept the risk set disable-plaintext 0 -- WIthout the '--' of course... ;-) Note the part about the risk, they must be really paranoid about those plaintext passwords. Have fun, Peter.-)
I think that disabling plain text password authentication by default is a good move for SuSE. If you're still using plain text passwords then something is wrong. There are very few email clients that don't support SSL these days. Things like telnet and ftp are obsolete (or should be) due to SSH and SFTP. Even cisco ships their IOS with ssh authentication now days. The fact of the matter is that over half of security breaches are from internal sources, so having a "firewall" isn't the end of security. If you believe that the data you're securing isn't important enough to need secure password authentication then perhaps that's acceptable to your company. To have decent security in place requires a layered security approach, meaning that you have more than one piece to secure everything. Setting up SSL is really not that hard, and using it on the clients usually only requires you to check a box. I would strongly suggest that you invest the time to use SSL for your email authentication, but obviously the end decision is based on the cost difference between doing that versus the risk of losing your data. The paranoia that SuSE is displaying here is simply derived from basic modern security principals. On Wed, 2004-01-14 at 08:07, Peter Hinterseer wrote:
Note the part about the risk, they must be really paranoid about those plaintext passwords.
-- David M. Fetter - http://www.fetterconsulting.com/ "The world is full of power and energy and a person can go far by just skimming off a tiny bit of it." Neal Stephenson - Snow Crash
Quoting David Fetter
I think that disabling plain text password authentication by default is a good move for SuSE. If you're still using plain text passwords then something is wrong. There are very few email clients that don't support SSL these days. Things like telnet and ftp are obsolete (or should be) due to SSH and SFTP. Even cisco ships their IOS with ssh authentication now days. The fact of the matter is that over half of security breaches are from internal sources, so having a "firewall" isn't the end of security. If you believe that the data you're securing isn't important enough to need secure password authentication then perhaps that's acceptable to your company. To have decent security in place requires a layered security approach, meaning that you have more than one piece to secure everything. Setting up SSL is really not that hard, and using it on the clients usually only requires you to check a box. I would strongly suggest that you invest the time to use SSL for your email authentication, but obviously the end decision is based on the cost difference between doing that versus the risk of losing your data. The paranoia that SuSE is displaying here is simply derived from basic modern security principals.
The problem is that it is a compile time option that doesn't appear to be fixable without recompiling it yourself. This problem bit me, too. I use IMAP solely to talk to the IMP webmail system that resides on the same machine. Since the imap port is host-firewalled off, only things that reside on that machine can access it. Having the machine connect to itself via SSL is laughable, especially on a machine that isn't all that powerful to begin with. SuSE should not be in the business of telling sysadmins what is, and what is not acceptable. Better default options are always preferrable, but to tell the sysadmin "you can't do this" is wrong. SuSE should be in the business of empowering the sysadmins, not making their lives more difficult. In most situations, yes, IMAP should have ssl, and that should definately be the default setting. However, there are situations where it is less than optimal, and thus it should be config option, not compile-time option.
-snip--
SuSE should not be in the business of telling sysadmins what is, and what is not acceptable. Better default options are always preferrable, but to tell the sysadmin "you can't do this" is wrong. SuSE should be in the business of empowering the sysadmins, not making their lives more difficult.
In most situations, yes, IMAP should have ssl, and that should definately be the default setting. However, there are situations where it is less than optimal, and thus it should be config option, not compile-time option.
In fairness to SuSE, the decison to change the default behavior of the UW Imap daemon was made by the program authors at UW. SuSE could have done a better job notifying people there was a significant change in the default behavior and that it would break all webmail clients. As for the Outlook Express imap problem...it has been known for some time that Microsoft's implementation of imap is badly broken. It has handshake timing issues which prevent reliable connections. MS has known about this for a long time and seems uninterested in fixing it. Entourage on the Mac side suffers from similar handshake problems. Adding ssl to the handshake seems to make the problems worse. peter
On Wednesday 14 January 2004 17:27, David Fetter wrote:
I think that disabling plain text password authentication by default is a good move for SuSE. If you're still using plain text passwords then something is wrong. There are very few email clients that don't support SSL these days. Things like telnet and ftp are obsolete (or should be) due to SSH and SFTP. Even cisco ships their IOS with ssh authentication now days. The fact of the matter is that over half of security breaches are from internal sources, so having a "firewall" isn't the end of security. If you believe that the data you're securing isn't important enough to need secure password authentication then perhaps that's acceptable to your company. To have decent security in place requires a layered security approach, meaning that you have more than one piece to secure everything. Setting up SSL is really not that hard, and using it on the clients usually only requires you to check a box. I would strongly suggest that you invest the time to use SSL for your email authentication, but obviously the end decision is based on the cost difference between doing that versus the risk of losing your data. The paranoia that SuSE is displaying here is simply derived from basic modern security principals.
I would fully agree with you ( I haven't talked to a telnet server in 7 years) if it weren't for the fact that one often-used application of imapd is to have it listening on localhost _only_ and have squirrelmail or another webmail app talk to it. This latest change breaks that. The same goes for telnet. Although it shouldn't be used to build a traditional connection, it serves me often to check services ('telnet hostname 25') so removing telnet "because it's insecure" would be a bad move. I'm speaking hypothetically of course, but you get the point. Maarten
David M. Fetter - http://www.fetterconsulting.com/
"The world is full of power and energy and a person can go far by just skimming off a tiny bit of it." Neal Stephenson - Snow Crash
Thank you so much Peter!
This worked. I thought it was unlike SuSE to leave a way out of this.
I grepped for "I accept the risk" in the package documentation - nothing.
Grepped for "disable-plaintext", found it in imaprc, which describes the
c-client.cf file... however very little detail given and it said that the
default is already 0! Some slightly improved documentation - e.g. a note in
the README.SuSE would be helpful here.
David Fetter - with regard to your comments, yes I agree that it's fine to
change defaults on packages. I was concerned that as a responsible IT
professional that has carefully weighed up the security implications I
couldn't undo this without recompiling the package. In our case we are a
small company and anyway clients are using Outlook Express connecting using
plain text/pop3 to our ISP anyway!
----- Original Message -----
From: "Peter Hinterseer"
-- snipped a lot of "I tried..." and "...didn't work" --
Really it's such a simple thing I want to do!
Can anyone help?
This is really not so hard to solve. SuSE's imap-2002 package released with 8.2 and 9.0 has to be explicitly enabled to accept plaintext passwords. Some file in the documentation mentions that. It also warns of the risks. But if all machines using this IMAP server are as you told us behind a firewall, this should be OK.
It is easily done by creating a file '/etc/c-client.cf' with the following content:
-- I accept the risk
set disable-plaintext 0 --
WIthout the '--' of course... ;-)
Note the part about the risk, they must be really paranoid about those plaintext passwords.
Have fun,
Peter.-)
-- Check the headers for your unsubscription address For additional commands, e-mail: suse-security-help@suse.com Security-related bug reports go to security@suse.de, not here
participants (6)
-
Carl Peto -
David Fetter -
Maarten v d Berg -
Peter Hinterseer -
peter＠frontierflying.com -
suse＠rio.vg