Chronology Current Month Current Thread Current Date
[Year List] [Month List (current year)] [Date Index] [Thread Index] [Thread Prev] [Thread Next] [Date Prev] [Date Next]

Re: End (?) of email question



On Sat, 20 Jun 1998, Sam Held wrote:

So to protect myself against the hackers' sniffers (that
captures your username and password), I have moved to a secure shell (ssh)
login. That is a 128 bit encryption security on my username and password.
Now, I was wondering if this can also be used to protect downloading
e-mail?
The different vendors of IMAP servers/clients have various alternatives
for "secure" login. Most implementations are default configured to pass
plain text for both user name and password. This makes it vulnerable to
sniffer attacks. Some imap servers offer 40 bit SSL login
as an option. This must be configured by the admin on the server side and
you must use a imap client that can support this type of encryption.
While 40 bit encryption is not "strong" it will foil most sniffers as
they are usually programmed to look for key words (login, password)
in plain text and will not notice/capture any type of encoded login
sequence.
CRAM, SCRAM, Kerberos and OTP are also being discussed as possible
encryption alternatives but there is no consensus from the various
server/client vendors.
It should be noted that most POP servers are also default configured with
plain text for both userid and password, making them vulnerable to sniffer
attacks.

Just in case
you wondering the attacks seem to be related to security holes in Linux
RedHat 5.0 (now corrected in 5.1) and users using the same username and
password on duplicate machines.
I think that there may be two issues here. The first is a vulnerability
to sniffer attacks. Any login sequence (pop, telnet, imap) that is not
encrypted is vulnerable to this type of attack. For a typical ethernet
network, anyone on your network could plug in a sniffer and capture all
traffic on the net, anything not encrypted is immediatly viewable.
The second issue is the specific security hole in some IMAP server
distributions. This problem allowed attackers to gain root privileges on
machines. By creating a buffer overflow in certain situations the
attacker could gain access to the system and execute commands as root.
I know that the problem existed with the University of Washington's
implementation of both IMAP and POP. This was the default server
bundled with the RedHat 5.0 release. For other Unix implementations if
the admin used a commercial IMAP or POP server (Netscape, HP, etc) then
there was no problem. If the admin used the free IMAP/POP server software
from UW then they were/are vulnerable.


Bruce Esser
Physics Teacher Something witty
Marian High School Should go here
http://marian.creighton.edu