205944 - IMAP client sends plaintext password even if server indicates it is disabled

Status: RESOLVED FIXED

(MailNews Core :: Networking: IMAP, defect)

Description

[Boi Sletterink]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4b) Gecko/20030507
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4b) Gecko/20030507

I configured our IMAP server (Dovecot 0.99.9.1) to accept plaintext passwords
only when the session is encrypted. Mozilla works fine when the "Use secure
connection" option is selected.

However, when that option is not set, Mozilla still sends the plaintext
password, which of course is not accepted by Dovecot. The following transcript
from Ethereal shows the conversation between Dovecot and Mozilla:

D: * OK dovecot ready.
M: 1 authenticate plain
D: 1 NO Plaintext authentication disabled.
M: 2 login "insecure" "mypassword"
D: 2 NO Plaintext authentication disabled.
M: 3 logout
D: * BYE Logging out
D: 3 OK Logout completed.

The problem I see with this is that even though the server responds with "1 NO
(message)" to the command "1 authenticate plain", Mozilla still goes ahead and 
tries to authenticate anyway. Since this is sensitive information, I'd really
like Mozilla not to send it since it is sent over a plaintext channel and the
server already indicated that it won't accept it anyway. It will be helpful to
improve security when someone forgets to turn on SSL.

Reproducible: Always

Steps to Reproduce:
1. Configure IMAP server to accept connections on the IMAP port (143)
2. Configure IMAP server to accept plaintext authentication only over SSL
3. Configure Mozilla to use said IMAP server with a valid user
4. Make sure "Use secure connection" is turned off
5. Snoop IMAP connections between Mozilla and IMAP server
6. Try to connect and collect password with snooper


Actual Results:  
M: 1 authenticate plain
D: 1 NO Plaintext authentication disabled.
M: 2 login "insecure" "mypassword"
D: 2 NO Plaintext authentication disabled.
M: 3 logout
D: * BYE Logging out
D: 3 OK Logout completed.

Expected Results:  
M: 1 authenticate plain
D: 1 NO Plaintext authentication disabled.
M: 3 logout
D: * BYE Logging out
D: 3 OK Logout completed.

Comment 1

[Kari Hurtta]

"authenticate plain" tries authentication with SASL mechanism "PLAIN".
"login" is imap's authentication command without using of SASL. These are not
related.


For disabling "LOGIN" RFC 2595 ( Using TLS with IMAP, POP3 and ACAP )
says following:

--------------------clip-----------------------clap---------------
3.2. IMAP LOGINDISABLED capability

   The current IMAP protocol specification (RFC 2060) requires the
   implementation of the LOGIN command which uses clear-text passwords.
   Many sites may choose to disable this command unless encryption is
   active for security reasons.  An IMAP server MAY advertise that the
   LOGIN command is disabled by including the LOGINDISABLED capability
   in the capability response.  Such a server will respond with a tagged
   "NO" response to any attempt to use the LOGIN command.

   An IMAP server which implements STARTTLS MUST implement support for
   the LOGINDISABLED capability on unencrypted connections.

   An IMAP client which complies with this specification MUST NOT issue
   the LOGIN command if this capability is present.

   This capability is useful to prevent clients compliant with this
   specification from sending an unencrypted password in an environment
   subject to passive attacks.  It has no impact on an environment
   subject to active attacks as a man-in-the-middle attacker can remove
   this capability.  Therefore this does not relieve clients of the need
   to follow the privacy mode recommendation in section 2.2.

   Servers advertising this capability will fail to interoperate with
   many existing compliant IMAP clients and will be unable to prevent
--------------------clip-----------------------clap---------------

Your transcript does not show that server was sending LOGINDISABLED
capability.

/ Kari Hurtta

Comment 2

[Timo Sirainen]

Dovecot would be sending LOGINDISABLED in CAPABILITY, if Mozilla actually
bothered to ask the capability. Mozilla shouldn't either rely on AUTHENTICATE
PLAIN to work unless there's AUTH=PLAIN in CAPABILITY. Actually Dovecot is here
buggy since it advertises both LOGINDISABLED and AUTH=PLAIN, have to fix that..

LOGINDISABLED has been added to latest IMAP4rev1 spec in rfc3501. It contains:

      (3) The following measures are in place:
         (a) The LOGINDISABLED capability is advertised, and [SASL]
         mechanisms (such as PLAIN) using plaintext passwords are NOT
         advertised in the CAPABILITY list.
      AND
         (b) The LOGIN command returns an error even if the password is
         correct.
      AND
         (c) The AUTHENTICATE command returns an error with all [SASL]
         mechanisms that use plaintext passwords, even if the password
         is correct.

Comment 3

[David :Bienvenu]

Mozilla DOES bother to ask for capability, but we ignore the LOGINDISABLED
capability. However, if you don't advertise AUTH=PLAIN, we won't use it.

Comment 4

[Timo Sirainen]

Dovecot would be sending LOGINDISABLED in CAPABILITY, if Mozilla actually
bothered to ask the capability. Mozilla shouldn't either rely on AUTHENTICATE
PLAIN to work unless there's AUTH=PLAIN in CAPABILITY. Actually Dovecot is here
buggy since it advertises both LOGINDISABLED and AUTH=PLAIN, have to fix that..

LOGINDISABLED has been added to latest IMAP4rev1 spec in rfc3501. It contains:

      (3) The following measures are in place:
         (a) The LOGINDISABLED capability is advertised, and [SASL]
         mechanisms (such as PLAIN) using plaintext passwords are NOT
         advertised in the CAPABILITY list.
      AND
         (b) The LOGIN command returns an error even if the password is
         correct.
      AND
         (c) The AUTHENTICATE command returns an error with all [SASL]
         mechanisms that use plaintext passwords, even if the password
         is correct.

Comment 5

[Chapman Flack]

See also bug 263000.

Comment 6

[Daniel Veditz [:dveditz]]

*** Bug 218901 has been marked as a duplicate of this bug. ***

Comment 7

[Sven Neuhaus]

Mozilla Mail issues the "capability" command the first time it connects to the
mail server after startup. Subsequent connections no longer send "capability"
(I'm assuming the information gets cached).

Here's a dump of the first connection after startup:

 * OK eulerei Cyrus IMAP4 v2.2.8 server ready
 1 capability
 * CAPABILITY IMAP4 IMAP4rev1 ACL QUOTA LITERAL+ MAILBOX-REFERRALS NAMESPACE
UIDPLUS ID NO_ATOMIC_RENAME UNSELECT CHILDREN MULTIAPPEND BINARY SORT
THREAD=ORDEREDSUBJECT THREAD=REFERENCES ANNOTATEMORE IDLE STARTTLS LOGINDISABLED
 1 OK Completed
 2 login "user" "cleartext"
 2 NO Login only available under a layer

Comment 8

[David :Bienvenu]

fixed as part of work for bug 60377 - we now respect LOGINDISABLED, and requery
for capability if we connect via TLS