-
Notifications
You must be signed in to change notification settings - Fork 168
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 #105
Comments
@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) ? |
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:
The second RFC added:
And a lot of libs/softs have all SCRAM-SHA-2 family support:
You can see more info, a list: scram-sasl/info#1 For example (not only one):
@SamWhited: There is no SHA-1 support in this project ;) |
@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. 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!
Details:
Thanks to @SamWhited! |
Good news, go-xmpp supports now SCRAM-SHA-1/SCRAM-SHA-256/SCRAM-SHA-512, a contrib from @mdosch! Now, last parts are "-PLUS" variants and SCRAM-SHA3-512(-PLUS) to complete. |
@mattn @Neustradamus |
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 I don't think it is helpful to ping the developer
several times in several issues/PRs. I know you are very excited
about this topic but nonstop pinging is noisy and disturbing for
other people and causing stress.
…On 02.11.2023 14:54, Neustradamus wrote:
@mattn: Can you look current @mdosch PR please?
- https://github.com/mattn/go-xmpp/pulls
Thanks in advance.
--
Reply to this email directly or view it on GitHub:
#105 (comment)
You are receiving this because you were mentioned.
Message ID: ***@***.***>
|
@Neustradamus make PR already if you want to be useful. This is going to be trivial task. |
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. |
Can you add supports of :
"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:
LDAP:
HTTP:
2FA:
IANA:
Linked to:
The text was updated successfully, but these errors were encountered: