Re: How to auto connect via SSH and Balsa?

[Brian Stafford <brian stafford uklinux net>]

On 2001.09.15 10:11:11 +0100 Jules Bean wrote:
> On Sat, Sep 15, 2001 at 10:52:16AM +0200, M . Thielker wrote:
> > Hi,
> > 
> > On 2001.09.15 09:29 Bojan Land wrote:
> > > and I don't see a place where to put a "command to run to establish a
> > > connection"... ?  Any clues?
> > 
> > if there was such a thing, it would be _very_ dangerous and insecure. As a
> > matter of fact, IMAP itself offers encryption and secure authentication, so
> > why not use that?
> 
> Why would that be insecure?
> 
> It would be much less insecure than, for example, running cleartext IMAP.
> 
> Encrypted IMAP has its own disadvantages: at least for the server I
> looked into, the encryption is two-way, and requires the server to
> have a clear-text copy of the password.

What mechanisms were in use?  SSL/TLS uses X.509 certificates for authentication.
Private key information and (certificate) passwords never travel across the network.
Public keys are exchanges *after* encryption is established.  By requiring
client certificates, the only use for a password is to decrypt the user's certificate
private key - netiher the passowrd or the private key are needed by the remote
host.

OTOH SASL mechanisms are another kettle of fish.  Certain mechanisms such as
CRAM-MD5 must compute responses to a challenge based on the password in use.
Unfortunately a salted hash of the password cannot be used in conjunction with
CRAM-MD5, however this need not require storage of clear text passwords, though
some implementations may choose to do so.  This still has to be better than
clear text passwords traversing the net.  Other SASL mechanisms have their
own sets of advantages and disadvantages.  PLAIN (or LOGIN) should never be
used in a clear-text connection, sadly many ignore the normative requirement
not to do so and provide them anyway.  Worse still, CRAM-MD5 is rarely available
despite a normative requirement that every SASL implementation must provide it.

Tunnelling over SSH does not improve matters as much as might be expected.  A search
through CERT's archives will reveal that password sniffing techniques and attacks
on weaknesses in the SSH protocol are rife (at least for SSHv1 - v2 is somewhat
more secure).  As discussed recently on the balsa list, tunnelling is evil anyway,
there are critical races that could be exploited by an attacker and in any case
it can be used to subvert security policy on the remote host.

Regards
Brian