#147 new
Bill Cole

Authentication broken in Version 1.2 (2170)

Reported by Bill Cole | June 2nd, 2011 @ 05:30 PM

After updating to 1.2(2170) MailMate is now trying to use CRAM-MD5 authentication for servers where it used LOGIN in prior versions. Because TLS is used for the connection to these servers, LOGIN is not an unsafe mechanism. Unfortunately, MailMate is doing CRAM-MD5 wrong. See http://www.ietf.org/rfc/rfc2195.txt for the definitive specification of how to implement CRAM-MD5. The errors I can identify from server logs are:

  1. It is using upper-case letters (A-F) rather than the lower-case letters (a-f) in the digest portion of the response string. (violates RFC2195 sect.2 p.2)
  2. It is prefacing the authentication response with an IMAP command token. (violates RFC2195 sect.2 p.3)

From the server logs (with the challenge string and its base64 form redacted):

15:54:12.464 5 IMAP-167747([66.73.230.190]) inp: A1 STARTTLS
15:54:12.464 5 IMAP-167747([66.73.230.190]) out: A1 OK begin TLS negotiation\r\n
15:54:12.732 4 IMAP-167747([66.73.230.190]) TLSv1 inp(77): client_hello: TLS-202702 created: method=DES3_SHA, residual=0, id=< 00 03 17 CE 4D E7 B2 24 1D E0 69 51 72 AC 6C 97 51 2C 7B EB CF 44 3B 41 55 82 6C CA B1 25 77 9B>
15:54:12.732 4 IMAP-167747([66.73.230.190]) TLSv1 out(70): server_hello
15:54:12.732 4 IMAP-167747([66.73.230.190]) TLSv1 out(3709): certificate
15:54:12.732 4 IMAP-167747([66.73.230.190]) TLSv1 out(0): server_hello_done
15:54:15.123 4 IMAP-167747([66.73.230.190]) TLSv1 inp(258): client_key_exchange
15:54:15.214 4 IMAP-167747([66.73.230.190]) security initiated
15:54:15.214 4 IMAP-167747([66.73.230.190]) TLSv1 inp(1): change_cipher
15:54:15.214 4 IMAP-167747([66.73.230.190]) TLSv1 out(1): change_cipher
15:54:15.214 4 IMAP-167747([66.73.230.190]) TLSv1 inp(12): finished
15:54:15.214 4 IMAP-167747([66.73.230.190]) TLSv1 out(12): finished
15:54:15.214 4 IMAP-167747([66.73.230.190]) TLS-202702(DES3_SHA) connection accepted for 'cipherspace.com'
15:54:16.119 5 IMAP-167747([66.73.230.190]) s-inp: A2 CAPABILITY
15:54:16.119 5 IMAP-167747([66.73.230.190]) s-out: * CAPABILITY IMAP4 IMAP4REV1 ACL NAMESPACE UIDPLUS IDLE LITERAL+ QUOTA ID MULTIAPPEND LISTEXT CHILDREN BINARY ESEARCH LOGIN-REFERRALS UNSELECT SASL-IR AUTH=LOGIN AUTH=PLAIN AUTH=CRAM-MD5 AUTH=DIGEST-MD5 AUTH=GSSAPI\r\nA2 OK completed\r\n
15:54:16.411 5 IMAP-167747([66.73.230.190]) s-inp: A3 AUTHENTICATE CRAM-MD5
15:54:16.411 5 IMAP-167747([66.73.230.190]) SASL-0(CRAM-MD5) out:
15:54:16.411 5 IMAP-167747([66.73.230.190]) s-out: + REDACTED==\r\n
15:54:16.692 5 IMAP-167747([66.73.230.190]) s-inp: A4 YmlsbF9jb2xlQGNpcGhlcnNwYWNlLmNvbSA4MEE5ODEzODAzNUU3MThGRTU1RTZEOTlBQzc5QjVBRg==
15:54:16.692 5 IMAP-167747([66.73.230.190]) s-out: A3 NO SASL parameters are incorrect\r\n

A MUA should not be needlessly changing how it does authentication for previously working sources. There's no strong reason to prefer CRAM-MD5 instead of a plaintext mechanism inside a TLS session, and clearly the implementation of CRAM-MD5 in MailMate has not been tested. It could be useful to have the SASL mechanism selectable by the user, since there are situations where a server may advertise mechanisms that function for some users but not others, depending on the nature of their records in an authentication backend.

Comments and changes to this ticket

  • benny

    benny June 2nd, 2011 @ 09:47 PM

    • State changed from “new” to “fixreleased”
    • Assigned user set to “benny”

    Thanks for the very detailed report. The problem with CRAM-MD5 has been fixed and a new version has been uploaded.

    The authentication method has been part of MailMate for a long time, but due to a bug it was not active. When I fixed the bug and it worked with all of my IMAP accounts I didn't think more about it, but it turns out that all of my IMAP accounts only provide AUTH=PLAIN. Bad excuse, I know.

    It seems there is still an issue with AUTH=PLAIN with some servers (Exchange 2007 and maybe others), but MailMate is going to retry with a plain login if it fails. I think I had a similar problem with SMTP where some servers would fail with the single-line form of AUTH=PLAIN, but they did work with the continuation request (just thinking aloud here).

Please Sign in or create a free account to add a new ticket.

With your very own profile, you can contribute to projects, track your activity, watch tickets, receive and update tickets through your email and much more.

New-ticket Create new ticket

Create your profile

Help contribute to this project by taking a few moments to create your personal profile. Create your profile ยป

Mac OS X email client.

Shared Ticket Bins

People watching this ticket

Pages