gen-smtp / gen_smtp

The extensible Erlang SMTP client and server library.
Other
683 stars 266 forks source link

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

Open Neustradamus opened 2 years ago

Neustradamus commented 2 years ago

Dear @gen-smtp team,

In first, I wish you a Happy New Year!

Can you add supports of:

You can add too:

Important history:

CRAM-MD5 to Historic:

RFC6331: Moving DIGEST-MD5 to Historic:

RFC8600: https://tools.ietf.org/html/rfc8600 (2019-06-21): https://mailarchive.ietf.org/arch/msg/ietf-announce/suJMmeMhuAOmGn_PJYgX5Vm8lNA 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].

But in "Best practices for password hashing and storage" expired I-D:


About Channel Binding (for -PLUS variants):

Some important XEPs:

Little details, to know easily:

After the jabber.ru MITM, Channel Binding is the solution:


SCRAM-SHA-1(-PLUS):

SCRAM-SHA-256(-PLUS):

SCRAM-SHA-512(-PLUS):

SCRAM-SHA3-512(-PLUS):

SCRAM BIS: Salted Challenge Response Authentication Mechanism (SCRAM) SASL and GSS-API Mechanisms:

IMAP:

LDAP:

HTTP:

JMAP:

2FA:

IANA:

SASL2:

Linked to:

seriyps commented 2 years ago

I implemented SCRAM-SHA-256 for Erlang's postgres driver, it was not the easiest thing =)

Is there a specific usecase? Maybe some overview article about SCRAM in SMTP?

Neustradamus commented 2 years ago

@seriyps: It will be excellent :)

Note, for example, that ProcessOne ejabberd and Erlang Solutions Mongoose IM have the support of SCRAM...

About "Mail", without libs, etc.: From https://github.com/scram-xmpp/info/issues/1.

SCRAM-SHA-1 and SCRAM-SHA-256:

SCRAM-SHA-1, SCRAM-SHA-256, SCRAM-SHA-512:

SCRAM-SHA-1(-PLUS), SCRAM-SHA-256(-PLUS), SCRAM-SHA-512(-PLUS):

SCRAM-SHA-1(-PLUS), SCRAM-SHA-224(-PLUS), SCRAM-SHA-256(-PLUS), SCRAM-SHA-384(-PLUS), SCRAM-SHA-512(-PLUS):

SCRAM-SHA-1:

Neustradamus commented 2 years ago

I have added the last RFC in the description: RFC9051: Internet Message Access Protocol (IMAP) - Version 4rev2:

I wish you a good reading, I know it is IMAP ^^

Neustradamus commented 10 months ago

Dear @gen-smtp, @seriyps,

I wish you a Happy New Year 2024!

Have you progressed on it?

Thanks in advance.

Vagabond commented 10 months ago

maybe the way to handle this is to make authentication pluggable and then we could make an auth module that used https://github.com/esl/fast_scram ?

Vagabond commented 10 months ago

Actually I guess we could just add it as an optional dep, although SCRAM does seem quite invasive as it appears to take several steps to authenticate. Also we'd need a stringprep implementation.

seriyps commented 10 months ago

We have a stringprep algorithm in epgsql. It could be extracted as a separate app I guess

https://github.com/epgsql/epgsql/blob/devel/src/epgsql_sasl_prep_profile.erl

Neustradamus commented 10 months ago

If you want, there are:

Fast_TLS: TLS / SSL OpenSSL-based native driver for Erlang / Elixir

Stringprep: Fast Stringprep implementation for Erlang / Elixir

seriyps commented 10 months ago

https://github.com/processone/stringprep is a NIF. Maybe it's ok. But maybe it's not :)

Vagabond commented 10 months ago

its probably going to be hard to do this without any NIFs, because there's a KDF involved

seriyps commented 10 months ago

@Vagabond I mean, Processone's stringprep (unicode password string normalization) is implemented as NIF, while we in epgsql did it in Erlang. Not sure how complete is it, because it was contributed from outside.

We did scram in Erlang as well, but it is quite ad-hoc https://github.com/epgsql/epgsql/blob/7ba52768cf0ea7d084df24d4275a88eef4db13c2/src/epgsql_scram.erl#L72-L130

Vagabond commented 10 months ago

well, the reason pure-erlang is bad for a KDF is that if the client can do the KDF much faster than the server, than the inclination is to weaken the KDF to retain server performance, which gives a malicious client an advantage.

seriyps commented 10 months ago

Ah, got it. It was ok for epgsql because epgsql is a client, not server

Neustradamus commented 2 weeks ago

It is possible to have help on this ticket?