Open Neustradamus opened 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?
@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:
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 ^^
Dear @gen-smtp, @seriyps,
I wish you a Happy New Year 2024!
Have you progressed on it?
Thanks in advance.
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 ?
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.
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
If you want, there are:
Fast_TLS: TLS / SSL OpenSSL-based native driver for Erlang / Elixir
Stringprep: Fast Stringprep implementation for Erlang / Elixir
https://github.com/processone/stringprep is a NIF. Maybe it's ok. But maybe it's not :)
its probably going to be hard to do this without any NIFs, because there's a KDF involved
@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
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.
Ah, got it. It was ok for epgsql because epgsql is a client, not server
It is possible to have help on this ticket?
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: