On Mon, 22 Nov 1999, Evgeny Stambulchik wrote:

> Omer <[EMAIL PROTECTED]> wrote:
> 
> >  Quite a lot of pop clients support apop (qpop, for instance).
> >  Granted, it's no ssh or ssl - but it's better than nothing.
> 
> Actually, one has to distinguish several security issues here:
> 1. Usage of encrypted versus plain-text passwords
> 2. Usage of different (from the system login) passwords
> 3. Encryption of the whole session (i.e., including the mail message body)
> 
> Theoretically speaking, as far as an email service(s) is concerned, one
> shouldn't worry about (1), given that (2) is satisfied. Indeed, what would a
> snooper do with one's email (== imap or pop) password? Only read his emails,
> but since the email is relayed over the Internet in plain text, it doesn't
> matter anyway. Or, putting it other way around, if you want privacy, use
> pgp/gpg, and your correspondence will remain private whether the imap/pop
> password is guessed or not. For the same reason, (3) isn't worth tinkering
> with either (again, talking about email).

Not so! What about a denial of service attack - someone who selectively
deletes emails from your mailbox so that you miss an opportunity?
The simple solution is APOP, as you indicate below.

 - yba

> 
> There is an important exception from this reasoning, though: users tend to
> forget special, per service, passwords and then try to use their system
> login&password pairs :). Therefore, even if the authentication fails, the
> true login&password pair is exposed to the world. So still, encrypted
> passwords should be preferred. This can be mostly ignored if the shell
> logins are disabled on the server altogether (a good thing anyway) and
> clients connect from inside a well-guarded firewall.
> 
> A good thing about Qualcom's pop server (aka qpopper) is that it can use a
> separate password DB AND use encrypted passwords (APOP). A bad thing is,
> only clients that understand it can work with it. On the other hand, as far
> as the open source software is concerned, it's a trivial task of modifying
> the authentication scheme (I once patched xfmail-1.2 to support APOP in an
> hour).
> 
> >  UW's IMAP server supports some sort of challange/response
> >  security mechanism (CRAM-MD5? I'm not sure).
> 
> It does, but then again clients should use it, too. Probably you refer to
> the _name_ of the alternative password DB it can use - but unless specially
> told, it will still authenticate using plain-text passwords.
> 
> >  Anyhow, it's not too hard (if anything, it's darn easy)
> >  to get stunnel or sslwrap running and allow your to enjoy
> >  the benefits of encrypted email (for the paranoid, anyhow).
> 
> Now, talking generally, not just about email, the problem with stunnel (or
> ssh forwarding) is that it should be setup for every service. Furthermore,
> protocols without fixed port number and UDP-based connections can't be
> encapsulated this way. A proper way of handling such situations may be VPN
> (virtual private network). Of course, a VPN setup requires super-user access
> rights on both sides of the link. There are several VPN implementations for
> Linux. Among free ones, VPND and VTUN are probably the most popular. I
> personally use VPND, since it doesn't require patching the kernel, though
> VTUN should be faster (for the same reason, being implemented on the kernel
> level). Still, performance is quite tolarable: say, with a 576-bit
> encryption key and a modest 486dx2 I get more than 100KB/s for NFS reads.
> 
> Regards,
> 
> Evgeny
> 
> 
> --
>    ____________________________________________________________
>   / Evgeny Stambulchik  <[EMAIL PROTECTED]>  \
>  /  Plasma Laboratory, Weizmann Institute of Science, Israel \  \
>  |  Phone : (972)8-934-3610  == | == FAX   : (972)8-934-3491 |  |
>  |  URL   :    http://plasma-gate.weizmann.ac.il/~fnevgeny/  |  |
>  |  Finger for PGP key >=====================================+  |
>  |______________________________________________________________|
> 
> =================================================================
> To unsubscribe, send mail to [EMAIL PROTECTED] with
> the word "unsubscribe" in the message body, e.g., run the command
> echo unsubscribe | mail [EMAIL PROTECTED]
> 


   EE 77 7F 30 4A 64 2E C5  83 5F E7 49 A6 82 29 BA    ~. .~   TclTek Ltd.
 =}-------------------------------------------------ooO--U--Ooo-----------{=
  - [EMAIL PROTECTED] - tel: +972.52.670.353, http://www.tcltek.co.il -


=================================================================
To unsubscribe, send mail to [EMAIL PROTECTED] with
the word "unsubscribe" in the message body, e.g., run the command
echo unsubscribe | mail [EMAIL PROTECTED]

Reply via email to