No authentication with DIGEST-MD5
Categories
(MailNews Core :: Networking: IMAP, enhancement)
Tracking
(Not tracked)
People
(Reporter: jwa, Assigned: ch.ey)
Details
(Whiteboard: [patchlove])
Attachments
(1 file, 4 obsolete files)
73.10 KB,
patch
|
Details | Diff | Splinter Review |
Comment 1•19 years ago
|
||
Updated•19 years ago
|
Assignee | ||
Comment 3•19 years ago
|
||
Comment 4•19 years ago
|
||
Comment 6•19 years ago
|
||
Assignee | ||
Comment 7•19 years ago
|
||
Assignee | ||
Comment 8•19 years ago
|
||
Comment 9•19 years ago
|
||
Assignee | ||
Comment 10•19 years ago
|
||
Comment 11•19 years ago
|
||
Assignee | ||
Comment 12•19 years ago
|
||
Comment 13•19 years ago
|
||
Assignee | ||
Comment 14•19 years ago
|
||
Assignee | ||
Updated•19 years ago
|
Comment 15•19 years ago
|
||
Assignee | ||
Comment 16•19 years ago
|
||
Comment 17•19 years ago
|
||
Assignee | ||
Comment 18•19 years ago
|
||
Assignee | ||
Comment 19•19 years ago
|
||
Comment 20•19 years ago
|
||
Assignee | ||
Updated•19 years ago
|
Assignee | ||
Comment 21•19 years ago
|
||
Comment 22•19 years ago
|
||
Updated•18 years ago
|
Assignee | ||
Comment 23•18 years ago
|
||
Assignee | ||
Comment 24•18 years ago
|
||
Assignee | ||
Updated•18 years ago
|
Comment 25•18 years ago
|
||
Updated•17 years ago
|
Comment 26•17 years ago
|
||
Comment 27•16 years ago
|
||
Comment 28•16 years ago
|
||
Comment 29•16 years ago
|
||
Comment 30•14 years ago
|
||
Updated•14 years ago
|
Comment 31•14 years ago
|
||
Comment 32•14 years ago
|
||
Updated•14 years ago
|
Updated•14 years ago
|
Comment 33•13 years ago
|
||
Comment 34•13 years ago
|
||
Comment 35•13 years ago
|
||
Comment 36•11 years ago
|
||
Comment 37•6 years ago
|
||
From https://tools.ietf.org/html/rfc2831 besides functional advantages, I see only one security advantage mentioned:
"compared to CRAM-MD5, DIGEST-MD5 prevents chosen plaintext attacks".
From RFC 6331:
"The MD5 hash is sufficiently weak to make a brute force attack on DIGEST-MD5 easy with common hardware".
I think the conclusion is, DIGEST-MD5 doesn't achieve what it intended to achieve.
I think using a secure SSL/TLS connection between client and server should be preferred.
I connected to a few IMAP servers, and none had DIGEST-MD5 as its only authentication mechanism. I think that nowadays most servers should offer another mechanism in combination with a secure connection.
I agree with wontfix and not spend time on implementing an md5-based mechanism in 2019.
Please add new comments if you can provide strong arguments why TB really should support it.
Comment 38•6 years ago
|
||
As a co-author of SASL DIGEST-MD5 (RFC 2831), I concur with both closing this as WONTFIX and RFC 6331 which moved that mechanism to IETF HISTORIC state. I also removed DIGEST-MD5 support from our server implementation some time ago.
I believe SASL SCRAM-SHA-256-PLUS and SCRAM-SHA-256 are mechanisms that could improve over passwords-over-TLS in the future, but at this point I'd say the industry consensus is that the risks of passwords-over-TLS do not yet justify the cost of investment in something better like SCRAM-SHA-256-PLUS (RFC 7677, RFC 5802/5803). I do hope that will change.
Comment 39•6 years ago
|
||
Yes, it is important to have all SCRAM-SHA-XXX-(PLUS) support!
SHA-1, SHA-2 family and SHA-3 family too.
Any news on it?
Comment 40•6 years ago
|
||
There are 2 tickets for the real ending for CRAM-MD5 and DIGEST-MD5:
- https://bugzilla.mozilla.org/show_bug.cgi?id=1579638
- https://bugzilla.mozilla.org/show_bug.cgi?id=1597113
Like Chris Newman (co-author of RFC 2831: SASL DIGEST-MD5) said, there is SCRAM since several years ago.
It is already done for XMPP:
- SCRAM-SHA-1: https://bugzilla.mozilla.org/show_bug.cgi?id=1267649
- SCRAM-SHA-256: https://bugzilla.mozilla.org/show_bug.cgi?id=1577688
SCRAM-SHA-1-PLUS and SCRAM-SHA-256-PLUS are missing because https://bugzilla.mozilla.org/show_bug.cgi?id=563276
People can look?
Tickets:
- For IMAP: https://bugzilla.mozilla.org/show_bug.cgi?id=1503382
- For POP: https://bugzilla.mozilla.org/show_bug.cgi?id=1597102
- For SMTP: https://bugzilla.mozilla.org/show_bug.cgi?id=1597103
- For LDAP: https://bugzilla.mozilla.org/show_bug.cgi?id=1597106
People can look?
RFCs:
- RFC5802: Salted Challenge Response Authentication Mechanism (SCRAM) SASL and GSS-API Mechanisms: https://tools.ietf.org/html/rfc5802
- RFC7677: SCRAM-SHA-256 and SCRAM-SHA-256-PLUS Simple Authentication and Security Layer (SASL) Mechanisms: https://tools.ietf.org/html/rfc7677 - since 2015-11-02
- RFC5056: On the Use of Channel Bindings to Secure Channels: https://tools.ietf.org/html/rfc5056
- RFC5929: Channel Bindings for TLS: https://tools.ietf.org/html/rfc5929
- RFC5803: Lightweight Directory Access Protocol (LDAP) Schema for Storing Salted: Challenge Response Authentication Mechanism (SCRAM) Secrets: https://tools.ietf.org/html/rfc5803
- RFC7804: Salted Challenge Response HTTP Authentication Mechanism: https://tools.ietf.org/html/rfc7804
IANA:
- Simple Authentication and Security Layer (SASL) Mechanisms: https://www.iana.org/assignments/sasl-mechanisms/sasl-mechanisms.xhtml
- Channel-Binding Types: https://www.iana.org/assignments/channel-binding-types/channel-binding-types.xhtml
Cyrus SASL supports:
- SCRAM-SHA-1
- SCRAM-SHA-1-PLUS
- SCRAM-SHA-224
- SCRAM-SHA-224-PLUS
- SCRAM-SHA-256
- SCRAM-SHA-256-PLUS
- SCRAM-SHA-384
- SCRAM-SHA-384-PLUS
- SCRAM-SHA-512
- SCRAM-SHA-512-PLUS
-> https://cyrusimap.org/sasl/sasl/authentication_mechanisms.html
-> https://github.com/cyrusimap/cyrus-sasl/commits/master
Dovecot SASL supports:
GNU SASL supports:
- SCRAM-SHA-1
- SCRAM-SHA-1-PLUS
-> http://www.gnu.org/software/gsasl/
CRAM-MD5 to Historic:
- https://tools.ietf.org/html/draft-ietf-sasl-crammd5-to-historic-00 // 20 November 2008
RFC6331: Moving DIGEST-MD5 to Historic
- https://tools.ietf.org/html/rfc6331 since July 2011
More informations:
Description
•