-
Notifications
You must be signed in to change notification settings - Fork 265
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
SCRAM-SHA-1(-PLUS) + SCRAM-SHA-256(-PLUS) + SCRAM-SHA-512(-PLUS) + SCRAM-SHA3-512(-PLUS) supports #302
Comments
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.: 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 ^^ |
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 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 We did |
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 |
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:
The text was updated successfully, but these errors were encountered: