msmtp
msmtp copied to clipboard
marlam
SCRAM-SHA-1(-PLUS) + SCRAM-SHA-256(-PLUS) + SCRAM-SHA-512(-PLUS) + SCRAM-SHA3-512(-PLUS) supports
CRAM-MD5 to Historic:
- https://tools.ietf.org/html/draft-ietf-sasl-crammd5-to-historic-00 // 20 November 2008
- https://tools.ietf.org/html/draft-zeilenga-luis140219-crammd5-to-historic-00 // June 29, 2017
RFC6331: Moving DIGEST-MD5 to Historic:
- https://tools.ietf.org/html/rfc6331 since July 2011
RFC 8600: "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):
- RFC5802: Salted Challenge Response Authentication Mechanism (SCRAM) SASL and GSS-API Mechanisms: https://tools.ietf.org/html/rfc5802
- RFC6120: Extensible Messaging and Presence Protocol (XMPP): Core: https://tools.ietf.org/html/rfc6120
SCRAM-SHA-256(-PLUS):
- 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
- RFC8600: Using Extensible Messaging and Presence Protocol (XMPP) for Security Information Exchange: 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
-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
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
Note, after SCRAM-SHA-1(-PLUS):
- GNU SASL (gsasl) supports SCRAM-SHA-256(-PLUS) since 1.9.1: http://git.savannah.gnu.org/gitweb/?p=gsasl.git;a=blob;f=NEWS;hb=HEAD
- Dovecot supports SCRAM-SHA-256(-PLUS) since 2.3.10: https://doc.dovecot.org/configuration_manual/authentication/authentication_mechanisms/
- Cyrus SASL/IMAP supports SCRAM-SHA-256(-PLUS) and more since 2.1.27: https://www.cyrusimap.org/sasl/sasl/authentication_mechanisms.html
- ...
Linked to:
- https://github.com/scram-xmpp/info/issues/1
- https://github.com/marlam/mpop-mirror/issues/6
I have no plans to implement any of this, for the following reason:
Nowadays every SMTP session must be protected with TLS. When TLS is active, there is no reason to use any SCRAM* method. (RFC 5802 says "there are some significant security concerns" with transmitting passwords over TLS-secured connections, but does not list any of them, and I have not seen a compelling argument for that statement yet.)
I therefore consider all methods except PLAIN, OAUTHBEARER, EXTERNAL (for TLS client certificates), LOGIN (strictly only for compatibility with Microsoft crap), and maybe GSSAPI (only in special situations) to be useless today.
Some of the deprecated methods like CRAM-MD5 etc are only left for backward compatibility and will probably be removed in the next larger update (1.10 or 2.0), so their presence is no reason to add SCRAM* methods.
So unless someone can convince me that any SCRAM* method over TLS offers a real (and not just theoretical) advantage over the simpler methods listed above, I will not add support for them.
Simon Josefsson convinced me that msmtp should support SCRAM-SHA-256. It now does.
However, I am still convinced that the SCRAM-* methods are just an unnecessary complexity and offer no real benefit.
@marlam: Thanks for your answer :)
@jas4711: Thanks a lot for your SCRAM-SHA-256 improvements in msmtp!
Can you look for mpop too, to have same into mpop and msmtp?
- https://github.com/marlam/mpop-mirror/search?q=scram-sha-1
- https://github.com/marlam/mpop-mirror/search?q=scram-sha-256
@marlam has not created a mimap yet, maybe soon?
@marlam: SCRAM-SHA-* is the evolution of DIGEST-MD5, a real security, please read the RFC6331.
But the PR is not merged and it is closed:
- https://github.com/marlam/msmtp-mirror/pull/40
And I do not find SCRAM-SHA-256:
- https://github.com/marlam/msmtp-mirror/search?q=scram-sha-1
- https://github.com/marlam/msmtp-mirror/search?q=scram-sha-256
Hi!
Can you look for mpop too, to have same into mpop and msmtp? [...] But the PR is not merged and it is closed: * #40. And I do not find SCRAM-SHA-256: * https://github.com/marlam/msmtp-mirror/search?q=scram-sha-256
Hi, I applied Simon's patch to both msmtp and mpop already. The reason you did not see it yet on Github is that the main repository is synced to the Github mirror only once per day. It should be there by now.
@MarlaN has not created a mimap yet, maybe soon?
What's a mimap?
@marlam: SCRAM-SHA-* is the evolution of DIGEST-MD5, a real security, please read the RFC6331.
I fully understand hat DIGEST-MD5 is terrible and obsolete; that's not my point. My point is that I don't see why anyone would need SCRAM*. Everybody uses TLS for everything today (or should be), and if that is the case, I see no practical benefit of SCRAM* vs good ol' PLAIN authentication:
-
Since you can assume TLS, you don't need channel binding and server authentication. This is just unnecessary complexity.
-
I don't see the use for authorization ids in the context of single-purpose protocols such as POP3, SMTP, IMAP, HTTP and so on (for which the SCRAM-* methods are intended). Again, unnecessary complexity.
-
I don't see the point of the stringprep requirements. The authentication method should just treat username and password as byte sequences, much like the Linux kernel treats file names. It is clear that they should in fact be valid UTF8 strings, but that can be handled purely on the user side; I don't see why the authentication method should need to deal with that. PLAIN works just fine with UTF8 user names and passwords precisely because it does not care. Unnecessary complexity again!
-
If the client stores the password encrypted and the server stores just a password hash, that's fine. I don't see why more "protection" of a password would be needed when TLS is active.
I may be wrong about these points, and if so, I would welcome to be corrected here. If you disagree, please give more information or a link.
@marlam: Thanks for your reply! Sorry for "N", I have edited.
I have not seen the @jas4711 PR here for mpop: https://github.com/marlam/mpop-mirror/pulls?q=is%3Apr It was directly in the main original source ^^
mimap would be an IMAP client, like mpop is a POP3 client ;) It will be really nice...
With SCRAM, the password on the server is not in PLAIN, better security, confidentiality.
mimap would be an IMAP client, like mpop is a POP3 client ;) It will be really nice...
Ah, ok. I'd like to do that, see here for a first thought: https://github.com/marlam/mpop-mirror/issues/4
With SCRAM, the password on the server is not in PLAIN, better security, confidentiality.
Sorry, not sufficient:
- With PLAIN, the password also does not need to be in clear text on the server, a hash is sufficient.
- The claim "better security, confidentiality" needs to be substantiated. As in "citation needed" (and not just a link to an RFC defining the method!).
To put it in other words, I'd like an answer to the question "In what way is SCRAM-SHA-256 better than PLAIN for password-based authentication in the context of a TLS-secured single-purpose protocol like IMAP or SMTP?" My current answer would be: in no way that is of practical relevance.
No with SCRAM the password is not saved into a database in clear.
Time to look for IMAP, you can see the last Internet-Draft:
- https://tools.ietf.org/html/draft-ietf-extra-imap4rev2
I have added mpop and msmtp in the list, but you have not done releases yet.
Note:
- GNU SASL (gsasl) supports SCRAM-SHA-256(-PLUS) since 1.9.1: http://git.savannah.gnu.org/gitweb/?p=gsasl.git;a=blob;f=NEWS;hb=HEAD
- Dovecot supports SCRAM-SHA-256(-PLUS) since 2.3.10: https://doc.dovecot.org/configuration_manual/authentication/authentication_mechanisms/
- Cyrus SASL/IMAP supports SCRAM-SHA-256(-PLUS) and more since 2.1.27: https://www.cyrusimap.org/sasl/sasl/authentication_mechanisms.html
- List here: https://github.com/scram-xmpp/info/issues/1
No with SCRAM the password is not saved into a database in clear.
And it is not with PLAIN either!
* GNU SASL (gsasl) supports SCRAM-SHA-256(-PLUS) since 1.9.1: http://git.savannah.gnu.org/gitweb/?p=gsasl.git;a=blob;f=NEWS;hb=HEAD * Dovecot supports SCRAM-SHA-256(-PLUS) since 2.3.10: https://doc.dovecot.org/configuration_manual/authentication/authentication_mechanisms/ * Cyrus SASL/IMAP supports SCRAM-SHA-256(-PLUS) and more since 2.1.27: https://www.cyrusimap.org/sasl/sasl/authentication_mechanisms.html
I know that these support SCRAM-SHA-256, but that does not answer the question "why would anyone want to use it instead of the much simpler PLAIN-over-TLS".
This is going nowhere. I must conclude that there is indeed no benefit to SCRAM.
After receiving feedback on an article I wrote about my doubts about SCRAM, I changed my position. SCRAM is indeed useful. See this update for the reasons that changed my mind.
Thanks for update! Big of you to reconsider. To be honest, I'm somewhere between your extreme positions. I do believe PLAIN is not ideal and that we can do better, and SCRAM is not bad. The complexity introduced with SCRAM over PLAIN is only worth it if it actually solves the problems we want to address: however, SCRAM does not REQUIRE servers to store passwords salted/hashed, and quite often they are stored in cleartext, which is WORSE than with PLAIN where deployment actually have started to have salted/hashed passwords fairly often. Secondly, the tls-unique channel binding is broken and does not offer the security guarantees that people thought. The idea of channel bindings is still good, IMHO, but there is two problems in SCRAM with it: 1) SCRAM chose to demand a broken channel binding, and updating it is not easy today, and 2) it was optional, so in practice its use won't be enforced. Finally, the unfortunate choice of having SCRAM be a family of mechanisms leads to plurality of hash methods being suggested which is detrimental to deployment.
Thanks for your changes about SCRAM-SHA-*.
I think the order is not good here:
- https://github.com/marlam/msmtp-mirror/blob/master/src/smtp.h#L77
And CRAM-MD5 and DIGEST-MD5 are less good than PLAIN.
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
Closing the circle here, I blogged about SCRAM concerns here: https://blog.josefsson.org/2021/06/08/whats-wrong-with-scram/
@marlam: We can thank @jas4711 who has worked on the support of the new security RFC in GNU SASL:
- RFC9266: Channel Bindings for TLS 1.3: https://tools.ietf.org/html/rfc9266
Little details, to know easily:
- tls-unique for TLS =< 1.2
- tls-server-end-point
- tls-exporter for TLS = 1.3
If you can test before merging and add support in msmtp?
- https://lists.gnu.org/archive/html/help-gsasl/2022-07/msg00003.html
- https://lists.gnu.org/archive/html/help-gsasl/2022-07/msg00004.html
Thanks in advance.
@jas4711, @marlam: I think that you have seen the jabber.ru MITM:
- https://notes.valdikss.org.ru/jabber.ru-mitm/
- https://snikket.org/blog/on-the-jabber-ru-mitm/
- https://www.devever.net/~hl/xmpp-incident
- https://blog.jmp.chat/b/certwatch
I am currently adding SCRAM-*-PLUS to msmtp (and later to mpop), using gnutls_session_channel_binding() to get the channel binding information, type EXPORTER for TLS 1.3 and UNIQUE for TLS <= 1.2.
I have a question regarding the AUTH capabilities advertised in a server greeting. Given that the SCRAM-* methods are able to protect against certain MITM attacks, Is it not a problem that a MITM could remove all the SCRAM-* methods from the server greeting, thereby making the client fall back to PLAIN or similar?
In other words, does a user have to enforce using a SCRAM-* method to benefit from its protections?
It was some time since I was well versed on the SCRAM downgrade protection complexity, but I believe that generally you are right that an adversary is able to MITM the TLS connection and make data modifications, AND if PLAIN is acceptable to the user/application, there is nothing SCRAM can do to protect against this.
What SCRAM-PLUS can offer is the ability to DETECT (and abort) passive TLS MITM's, since the channel binding will fail. If both client and server supports SCRAM+SCRAM-PLUS, then even SCRAM will allow detection (and abort) of active TLS attacks.
So ideally you would want to enforce at least SCRAM to any server that at some point offers SCRAM, and ideally anything less than SCRAM should not ever be acceptable to users/applications by default. I do understand that the e-mail world is far behind the HTTPS world here though, so this is usually not that feasible.
To compare with the jabber.ru issue: if clients (and servers) had supported SCRAM-PLUS, then you would have gotten connection failures and notice the passive TLS MITM before the certificate expired. The attacker could turn active and remove SCRAM+SCRAM-PLUS but this would be more costly than a pure passive attack.
Thank you for this information, it helps.
So in a first step, to not break existing setups, users of msmtp and mpop will have to manually select a SCRAM-* method to prevent these kinds of downgrade attacks.
In a second step, I'd like to add a simpler flag that enforces SCRAM-*[-PLUS] authentication without requiring the user to select one specific method manually, and recommend that flag prominently in all documentation and examples.
In the future, when/if SCRAM-* is widely supported in servers, this flag should then become the default, but that would break setups where the server does not support SCRAM-*...
@marlam: Thanks for your comments and thanks to @jas4711 for comments too :)
I take the opportunity to say that I have requested to @jas4711 to add "tls-server-end-point" support in GSASL too:
- https://gitlab.com/gsasl/gsasl/-/issues/13
In the specified ticket, I have added links to XEPs about SCRAM.
I would ignore tls-server-end-point and focus on mandatory SCRAM-PLUS with tls-exporter. If there is ever a serious significant use-case for non-plus SCRAM or tls-server-end-point, it could be added later, but I believe adding complexity to support them is counter-productive to reach a SCRAM-PLUS with tls-exporter world.
@jas4711, it is in XEPs:
- XEP-0388: Extensible SASL Profile: https://xmpp.org/extensions/xep-0388.html
- XEP-0440: SASL Channel-Binding Type Capability: https://xmpp.org/extensions/xep-0440.html
- XEP-0474: SASL SCRAM Downgrade Protection: https://xmpp.org/extensions/xep-0474.html
- XEP-0480: SASL Upgrade Tasks: https://xmpp.org/extensions/xep-0480.html
@marlam: @mbhangui has added supports in indimail-mta, he has done talks with @jas4711 too:
- https://github.com/search?q=owner%3Ambhangui+scram&type=issues
- https://github.com/search?q=owner%3Ambhangui+scram&type=pullrequests
Manvendra has helped @schengawegga for Net_SMTP too.
If there is any I can help, please let me know. I can provide a setup that provides accounts supporting SCRAM and SCRAM PLUS methods for authentication.
Regards Manny
On Thu, 16 Nov, 2023, 17:11 Neustradamus, @.***> wrote:
@marlam https://github.com/marlam: @mbhangui https://github.com/mbhangui has added support in indimail-mta, he has done talks with @jas4711 https://github.com/jas4711 too:
- https://github.com/search?q=owner%3Ambhangui+scram&type=issues
- https://github.com/search?q=owner%3Ambhangui+scram&type=pullrequests
Manvendra has helped @schengawegga https://github.com/schengawegga for Net_SMTP too.
— Reply to this email directly, view it on GitHub https://github.com/marlam/msmtp-mirror/issues/36#issuecomment-1814281030, or unsubscribe https://github.com/notifications/unsubscribe-auth/AB6RQLP3F7PWBKHWHMBGJMDYEX3VZAVCNFSM4TJNJOCKU5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TCOBRGQZDQMJQGMYA . You are receiving this because you were mentioned.Message ID: @.***>
Support for SCRAM-SHA-256-PLUS and SCRAM-SHA-1-PLUS is now in the git repository.
This is tested so far against Exim via TLS 1.2 and TLS 1.3, but this basically tests a GnuTLS/GSASL client against a GnuTLS/GSASL server, so any additional testing is very welcome.
A future patch will likely introduce auth=scram-plus and auth=scram support so that the user at least does not have to care about the hash-du-jour to get the security benefits of the scram methods.
The same code is now also in mpop for POP3. If you can test this, please do.
Support for SCRAM-SHA-256-PLUS and SCRAM-SHA-1-PLUS is now in the git repository.
This is tested so far against Exim via TLS 1.2 and TLS 1.3, but this basically tests a GnuTLS/GSASL client against a GnuTLS/GSASL server, so any additional testing is very welcome.
Yay! Dovecot support SCRAM (but not SCRAM-PLUS, I think) and is fairly easy to interop-test against: https://gitlab.com/gsasl/gsasl/-/blob/b21aa50acebcf1350832aba4af8fc7f84bb68f3b/.gitlab-ci.yml#L651
A future patch will likely introduce
auth=scram-plusandauth=scramsupport so that the user at least does not have to care about the hash-du-jour to get the security benefits of the scram methods.
Makes sense, although I think it is one of the disadvantages with SCRAM: it leads to UX complexity like this, instead of just providing secure defaults and reduce UX complexity. Web browser security has solved that, but it seems SMTP/IMAP/POP3/XMPP is stuck in older design patterns. No fault of msmtp/mpop, of course, but just a general observation.
/Simon
@marlam: Thanks for your improvements!
@jas4711: @stephanbosch has added SCRAM in Dovecot and he has commented here:
- https://github.com/python/cpython/issues/95341#issuecomment-1802366034
At the same time, you can see tls-server-end-point (in more tls-unique and tls-exporter) in xmpp lib used ejabberd...
- https://github.com/search?q=org%3Aprocessone+tls-server-end-point&type=code
I have more questions about SCRAM...
I was told that if a server stores the salted and hashed password, then stealing that allows impersonating the client, so it's no better than storing clear text passwords.
Then what is the server supposed to store instead?
In GSASL, what is SERVERKEY and STOREDKEY, and how do they relate to SCRAM_SALTED_PASSWORD? All of those seem to be derived from PASSWORD using SCRAM_ITER and SCRAM_SALT.
I hope that the manual covers this, see: https://www.gnu.org/software/gsasl/manual/html_node/SCRAM.html#SCRAM
Yes it is preferential to store SERVERKEY/STOREDKEY on the server, however I believe this advantage is exagerated: if you steal them, you only need one active MITM-attack to be able to compute the password-equivalents anyway. I think this is another example of were the SCRAM design introduces complexity that have questionable security advantage in the real world. The complexity required to support SERVERKEY/STOREDKEY, and security concerns as a consequence, may be larger than the slight theoretical gain that is won.
But does msmtp/mpop implement a server?