SCRAM-SHA-1-PLUS + SCRAM-SHA-256-PLUS + SCRAM-SHA-512-PLUS + SCRAM-SHA3-512(-PLUS) supports
Neustradamus opened this issue · 21 comments
Can you add supports of :
- SCRAM-SHA-1
- SCRAM-SHA-1-PLUS
- SCRAM-SHA-224
- SCRAM-SHA-224-PLUS
- SCRAM-SHA-256
- SCRAM-SHA-256-PLUS
- SCRAM-SHA-384
- SCRAM-SHA-384-PLUS
- SCRAM-SHA-512
- SCRAM-SHA-512-PLUS
- SCRAM-SHA3-512
- SCRAM-SHA3-512-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
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:
@mattn: Any news?
@mattn: If you need help, please look other libs/softs which support all other SCRAM-SHA-1(-PLUS) and SCRAM-SHA-2(-PLUS) family (224/256/384/512) in more than unsecure MD5.
It is really an important request for security.
I'm not familier to the SCRAM-SHA-1(-PLUS) and SCRAM-SHA-2(-PLUS) but should I change hash strong algorism (ex sha256/sha512) ?
I'm not familier to the SCRAM-SHA-1(-PLUS) and SCRAM-SHA-2(-PLUS) but should I change hash strong algorism (ex sha256/sha512) ?
No, the SHA1 is used in an HMAC and is still safe from the various SHA1 attacks that have been publicized recently.
@mattn: Look the SCRAM RFC, it is a better security.
Originaly (first RFC) there were only:
- SCRAM-SHA-1
- SCRAM-SHA-1-PLUS (normal with TLS binding in more)
The second RFC added:
- SCRAM-SHA-256
- SCRAM-SHA-256-PLUS
And a lot of libs/softs have all SCRAM-SHA-2 family support:
- SCRAM-SHA-224
- SCRAM-SHA-224-PLUS
- SCRAM-SHA-256
- SCRAM-SHA-256-PLUS
- SCRAM-SHA-384
- SCRAM-SHA-384-PLUS
- SCRAM-SHA-512
- SCRAM-SHA-512-PLUS
You can see more info, a list: scram-sasl/info#1
For example (not only one):
- Jackal: An XMPP server written in Go (Golang)
@SamWhited: There is no SHA-1 support in this project ;)
Adding all SCRAM in a one time is the best solution to do not used the unsecured MD5.
Look the SCRAM RFC, it is a better security.
@Neustradamus I think we've had this discussion before, but I'll say it again for the benefit of this thread: it is dangerous to make these sorts of assumptions without understanding the underlying crypto. SCRAM-SHA-1 is still safe and there is no reason to raise alarm.
Furthermore, the other variants you list (other than SHA1 and SHA-256) are not real variants in the SCRAM family, they have never been vetted by the IETF and never been standardized and therefore should be avoided. Just because you can shove another hash function into the HMAC doesn't mean you should: bigger numbers aren't always better. To be clear: I don't see how using any of those hashes could cause any sort of security issue either, but they are not used by the community and are not standardized, if you try to make them up now and then the community standardizes on a version that makes other tweaks besides just changing the hash things will be broken. Please just follow the standard and let the IETF do their job.
Back to the difference between using SHA1 and SHA-256: there should be little to no practical difference in terms of security. Instead, we need to think about upgrade paths and what the community is using. Right now SHA-1 is recommended and widely deployed, SHA-256 is very rarely used and the upgrade path is non-existent because of the way SCRAM works. It may or may not be worth supporting, but let's not try to create security issues where none exist.
@SamWhited: Have you looked here?
Yes, I am aware that this library is MD5 only. I'm not saying that we should avoid SCRAM-SHA-256, just that your assumption that it is better for security is wrong and should be avoided. If I have misunderstood what you were saying, I apologize. I think we're in general agreement that SCRAM should be supported :)
Here, I have requested all SCRAM for have compatibility with all libs/softs and old products.
More and more projects have now a better SCRAM compatibility.
I thank all devs who have contributed.
The future has started ;)
XMPP servers remove the old history unsecured MD5 support, any news on it?
@mattn: Have you looked for adding SCRAM?
In more: It is official for TLS 1.3 Binding!
- RFC 9266: Channel Bindings for TLS 1.3: https://tools.ietf.org/html/rfc9266
Details:
- tls-unique for TLS =< 1.2
- tls-exporter for TLS = 1.3
Thanks to @SamWhited!
Good news, go-xmpp supports now SCRAM-SHA-1/SCRAM-SHA-256/SCRAM-SHA-512, a contrib from @mdosch!
Thanks a lot!
Now, last parts are "-PLUS" variants and SCRAM-SHA3-512(-PLUS) to complete.
@mattn @Neustradamus
Can you please review mdosch@68eae8c
I wanted to create a PR here but gh also adds some other commits to the PR (maybe because my branch diverged from the master branch due to my other PRs) so I closed it.
It was surprisingly difficult to get that merged on top of my previous PRs. So, if you decide whether you want to merge my earlier PRs or not I will create a new PR afterwards on top of the master branch by that time.
@mattn: Note that it is important to look it quicly...
There is a recent history with jabber.ru MITM and SCRAM-SHA-*-PLUS is the security solution!
Some sources about jabber.ru:
@Neustradamus make PR already if you want to be useful. This is going to be trivial task.
Stop annoing people with your demands.
All algorithms that are relevant in xmpp are supported now (SCRAM-SHA-1, SCRAM-SHA-256, SCRAM-SHA-512 include their PLUS variants), therefore I'm closing this issue.