pear
RFC6331: Moving CRAM-MD5, DIGEST-MD5 and LOGIN to Historic
20 November 2008: CRAM-MD5 to Historic:
- https://tools.ietf.org/html/draft-ietf-sasl-crammd5-to-historic-00
29 June 2017: CRAM-MD5 to Historic:
- https://tools.ietf.org/html/draft-zeilenga-luis140219-crammd5-to-historic-00
July 2011: RFC6331: Moving DIGEST-MD5 to Historic:
- https://tools.ietf.org/html/rfc6331
I add same about SCRAM-MD5.
There are now:
- July 2010: RFC5802: Salted Challenge Response Authentication Mechanism (SCRAM): SASL and GSS-API Mechanisms: https://tools.ietf.org/html/rfc5802 (SCRAM-SHA-1 and SCRAM-SHA-1-PLUS)
- July 2010: RFC5803: Lightweight Directory Access Protocol (LDAP) Schema for Storing Salted: Challenge Response Authentication Mechanism (SCRAM) Secrets: https://tools.ietf.org/html/rfc5803
- November 2015: RFC7677: SCRAM-SHA-256 and SCRAM-SHA-256-PLUS: Simple Authentication and Security Layer (SASL) Mechanisms: https://tools.ietf.org/html/rfc7677
Soon:
- SCRAM-SHA-512(-PLUS): https://tools.ietf.org/html/draft-melnikov-scram-sha-512
- SCRAM-SHA3-512(-PLUS): https://tools.ietf.org/html/draft-melnikov-scram-sha3-512
I think we´ve done this with PR #76. @Neustradamus do you agree with this and we can close this issue successfully?
After a little bit of research and a few mails with @Neustradamus, we both agree that the authentication methods CRAM-MD5, DIGEST-MD5, LOGIN and PLAIN are not secure enough to use it in the future. In PR #76, i´ve done a few changes to inform the users about the security issue using this authentication methods.
The question is, what are the next useful steps?
The suggestion of @Neustradamus was, to remove CRAM-MD5, DIGEST-MD5 and LOGIN. Only PLAIN should stay in the Class, because there are Mailservers out there wich only supports PLAIN as authentication method.
I am not sure about that, because i don´t want to make this library useless for some users wich Mailservers do not support more secure authentication methods.
My idea was, to make this authentications methods only useable if a TLS connection is established. Because the credentials were transfered through a more secure connection layer. Than the authentication method should not be a security issue. Or am I wrong in my assumption?
@till @jparise what do you think about that? do you know any security or encryption experts who can give a suggestion about that?
@till @jparise what do you think about that? do you know any security or encryption experts who can give a suggestion about that?
Because this is a client (not server) library, I think it's useful to continue offering support for these methods but also help end users make informed decisions about their security.
@till @jparise what do you think about that? do you know any security or encryption experts who can give a suggestion about that?
Because this is a client (not server) library, I think it's useful to continue offering support for these methods but also help end users make informed decisions about their security.
@jparise i agree. What do you think about my suggestion to make them only available with TLS? Do you think this would remove the security gap, using this unsecure methods? I am not a deep security expert. Do you know an security encryption experts?
@till @jparise what do you think about that? do you know any security or encryption experts who can give a suggestion about that?
Because this is a client (not server) library, I think it's useful to continue offering support for these methods but also help end users make informed decisions about their security.
@jparise i agree. What do you think about my suggestion to make them only available with TLS? Do you think this would remove the security gap, using this unsecure methods? I am not a deep security expert. Do you know an security encryption experts?
I think I'd apply the same reasoning: leave them available but caution users not to use them in insecure ways.
I would support removing them entirely in a new major version.
The 1.11.0 release has done an important progress, DIGEST-MD5 is DEPRECATED:
- https://github.com/pear/Net_SMTP/releases/tag/1.11.0
And several SCRAM supports have been added (not -PLUS variants at this time):
- https://github.com/pear/Net_SMTP/issues/57