SCRAM-SHA-1(-PLUS) + SCRAM-SHA-256(-PLUS) + SCRAM-SHA-512(-PLUS) + SCRAM-SHA3-512(-PLUS) supports

[Neustradamus]

Dear @PHPMailer team,

It is time to support secure mechanisms, and it is needed in RFC9051: Internet Message Access Protocol (IMAP) - Version 4rev2.

Can you add supports of :

• SCRAM-SHA-1
• SCRAM-SHA-1-PLUS
• SCRAM-SHA-256
• SCRAM-SHA-256-PLUS
• SCRAM-SHA-512
• SCRAM-SHA-512-PLUS
• SCRAM-SHA3-512
• SCRAM-SHA3-512-PLUS

You can add too:

• SCRAM-SHA-224
• SCRAM-SHA-224-PLUS
• SCRAM-SHA-384
• SCRAM-SHA-384-PLUS

"When using the SASL SCRAM mechanism, the SCRAM-SHA-256-PLUS variant SHOULD be preferred over the SCRAM-SHA-256 variant, and SHA-256 variants [RFC7677] SHOULD be preferred over SHA-1 variants [RFC5802]".

• SCRAM-SHA-1(-PLUS):
  -- https://tools.ietf.org/html/rfc5802
  -- https://tools.ietf.org/html/rfc6120

• SCRAM-SHA-256(-PLUS):
  -- https://tools.ietf.org/html/rfc7677 since 2015-11-02
  -- https://tools.ietf.org/html/rfc8600 since 2019-06-21: https://mailarchive.ietf.org/arch/msg/ietf-announce/suJMmeMhuAOmGn_PJYgX5Vm8lNA

• 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

https://xmpp.org/extensions/inbox/hash-recommendations.html

-PLUS variants:

• 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
• Channel-Binding Types: https://www.iana.org/assignments/channel-binding-types/channel-binding-types.xhtml
• RFC 9266: Channel Bindings for TLS 1.3: https://tools.ietf.org/html/rfc9266

IMAP:

• RFC9051: Internet Message Access Protocol (IMAP) - Version 4rev2: https://tools.ietf.org/html/rfc9051

LDAP:

• RFC5803: Lightweight Directory Access Protocol (LDAP) Schema for Storing Salted: Challenge Response Authentication Mechanism (SCRAM) Secrets: https://tools.ietf.org/html/rfc5803

HTTP:

• RFC7804: Salted Challenge Response HTTP Authentication Mechanism: https://tools.ietf.org/html/rfc7804

2FA:

• Extensions to Salted Challenge Response (SCRAM) for 2 factor authentication: https://tools.ietf.org/html/draft-melnikov-scram-2fa

IANA:

• Simple Authentication and Security Layer (SASL) Mechanisms: https://www.iana.org/assignments/sasl-mechanisms/sasl-mechanisms.xhtml

Linked to:

• State of Play scram-sasl/info#1

[Synchro]

PHPMailer doesn't support IMAP at all, so this is all irrelevant.

[Neustradamus]

@Synchro: It must be added for SMTP like old and unsecure mechanisms.

You can see old and unsecure mechanisms here:

• https://github.com/search?q=repo%3APHPMailer%2FPHPMailer+cram-md5&type=code
• https://github.com/search?q=repo%3APHPMailer%2FPHPMailer+LOGIN&type=code

Other projects have already SCRAM.

SCRAM-SHA-*-(PLUS) replaces old unsecure SCRAM-MD5, DIGEST-MD5 and CRAM-MD5.
PLAIN replaces LOGIN but it is not really secure.

Thanks in advance.

[Synchro]

You're really missing the point here. A lack of support for newer protocols has no bearing on whether we should drop older ones because it's not a client library's call to make. There's no "must" about it. It's all academic anyway – there is almost no security difference between any of them if you're using them over TLS. login vs plain is also uninteresting – they are nearly the same, both are old, both work very well, and both are still extremely common (though cram-md5 is rare). If you're not using TLS it's a different matter, but essentially everybody is (and should be). If you told me that gmail was thinking of dropping XOAUTH2 in favour of these new schemes, it might be interesting, but they're not about to do that.
If you can be bothered to write support for them, I'll accept a PR, but it's really an exercise in RFC box-ticking rather than anything actually useful; it's not as if anyone is being prevented from connecting to anything.