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

[Neustradamus]

RFC8600:

"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

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

• https://tools.ietf.org/html/draft-melnikov-scram-bis

-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
• Channel Bindings for TLS 1.3: https://datatracker.ietf.org/doc/html/rfc9266

IMAP:

• RFC9051: Internet Message Access Protocol (IMAP) - Version 4rev2: https://tools.ietf.org/html/rfc9051

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

JMAP:

• RFC8621: The JSON Meta Application Protocol (JMAP) for Mail: https://tools.ietf.org/html/rfc8621

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:

• State of Play scram-sasl/info#1

[dirmgr]

I can consider adding support for the SCRAM-SHA-1 and SCRAM-SHA-256 authentication mechanisms. I don’t believe that it’s feasible to add support for the PLUS variants at this time because it does not appear that Java SE includes support for channel binding. It may be possible to get that through other libraries, like the one that Bouncy Castle provides, but the LDAP SDK does not and will not ever require any external dependencies other than Java SE, so that’s not an option. However, the LDAP SDK’s SASL support is extensible, so if that’s a deal-breaker, then anyone could implement support for the algorithms on their own if necessary.

I’ve been very hesitant to add support for these mechanisms in the past because I do not believe that they are secure. I’ll grant you that they’re better than CRAM-MD5 and DIGEST-MD5, but that’s an extremely low bar, and those mechanisms are only supported for legacy purposes. I’m not going to remove them from the LDAP SDK for the sake of backward compatibility, but I would also never recommend their use.

The primary benefit that the SCRAM mechanisms claim over other mechanisms (like LDAP simple binds, or the PLAIN SASL mechanism), is that the client never directly provides the password to the server, but instead only provides proof that it knows the password. There are two potential upsides to this:

• It is theoretically possible to have the authentication traffic in the clear without requiring a negotiated security layer. However, this is directly contradicted by the specification, stating that it’s only intended to be used over a connection with an external security later, like TLS. Further, even if you ignore that and send the authentication requests in the clear, that does nothing to protect any of the other communication on that connection, which may also involve sensitive data.

• The server isn’t given the password directly, and therefore can’t impersonate the user in other services (by trying to authenticate with the same username and password). This is the advantage touted by the specification, but it just doesn’t hold water. It suggests that the client doesn’t trust the server with the password, and yet the client must have already provided that very password to the server at some point in the past, because the server must either store that password in a reversible form that allows it to gain access to its clear-text representation, or it must have stored a version of the password derived by pre-computing a portion of the proof.

Presumably, the client has no insight into whether the server stores the password in a reversible or partially-computed form, and therefore if it doesn’t trust the server with the password at authentication time, it may not actually be deriving any benefit from using a SCRAM-based mechanism because the server might have access to it anyway. But either case leads to very bad news in the case of a data breach. If the passwords are stored in a reversible form, then there’s a very good chance that the attacker also got the information needed to reverse them and now has access to the clear-text passwords. If the passwords are stored in the pre-computed form, then that’s even worse because you can guarantee that the attacker has what they need to authenticate to the server (at least using a SCRAM-based mechanism) because that pre-computed form is even better than the clear-text password because it requires even less effort on the attacker’s part to use it.

There are other serious security-related side effects if the server is going to support these algorithms. Off the top of my head, the two biggest ones are:

• If the server does store the passwords in a pre-computed form, then you’re only going to be able to use one SCRAM variant per user (unless the server generates multiple pre-computed forms). The reason is that different variants have different pre-computed forms. If the server stores my password in a pre-computed form for SCRAM-SHA-1, then I can’t authenticate with SCRAM-SHA-256 because the pre-computed password isn’t compatible for that.

• Regardless of whether the password is stored in the clear or in a reversible form, the need to support SCRAM variants means that you can’t store it in a stronger, much more brute-force-resistant form like PBKDF2, bcrypt, scrypt, or Argon2. These algorithms are designed to offer a good degree of protection in the event that their encoded representation gets exposed; if a user has a strong enough password, then it is computationally infeasible to break it (at least, based on current understandings of those algorithms). You can’t get this if you want to support a SCRAM variant, regardless of whether you’re using the reversible form or the pre-computed form. I do know that you can potentially get some of this benefit from the pre-computed form by using a high iteration count, but that’s completely irrelevant if the pre-computed form is exposed because you can just use that pre-computed value directly without needing to know the clear-text password used to generate it.

Like I said, I’ll go ahead and look into adding support for SCRAM-SHA-1 and SCRAM-SHA-256. I wouldn’t have done so without a request because of the security problems outlined above, but the work to support them really isn’t all that substantial. But I would recommend against actually using these authentication mechanisms unless you need them for legacy purposes. Using LDAP simple authentication or SASL PLAIN over a TLS-encrypted connection is just as strong and gives the server much better options for securing the passwords.

[Neustradamus]

-PLUS variants and Java: https://bugs.openjdk.java.net/browse/JDK-6491070

Yes you can already add support for SCRAM-SHA-1, SCRAM-SHA-256 and SCRAM-SHA-512?

[dirmgr]

I've just committed a change that adds client-side support for the SCRAM-SHA-1, SCRAM-SHA-256, and SCRAM-SHA-512 SASL mechanisms. Please test it and let me know if it works.

[Neustradamus]

Thanks @dirmgr!
I will see for tests with @tigase, @igniterealtime and @jitsi teams!

@jerboaa: About: https://bugs.openjdk.java.net/browse/JDK-6491070, it is done?
If it does not, can you look? It will be used by ldapsdk etc.
Thanks in advance!

[dirmgr]

Note that even if Java SE adds support for channel binding in a future release, the LDAP SDK is not likely to be updated to make use of it. The LDAP SDK currently offers support for Java SE 7 and later, and because we have customers using it on those older platforms, we have no plans to drop that support any time soon.

However, the LDAP SDK is extensible, and you're certainly free to implement your own support for SASL mechanisms that do make use of channel binding.

[dirmgr]

FYI, LDAP SDK version 4.0.12 has been released and includes client-side support for the SCRAM-SHA-1, SCRAM-SHA-256, and SCRAM-SHA-512 SASL mechanisms.

[Neustradamus]

@dirmgr: Thanks :)

Channel Binding?

• https://www.google.com/search?q="java+se+channel+binding"
• https://docs.oracle.com/javase/7/docs/api/org/ietf/jgss/ChannelBinding.html
• https://docs.oracle.com/en/java/javase/13/docs/api/java.security.jgss/org/ietf/jgss/ChannelBinding.html

[Neustradamus]

@dirmgr: I have changed the name for have only missing parts :)

[Neustradamus]

@dirmgr: Why not used BouncyCastle for TLS binding like Tigase?

• https://www.bouncycastle.org/
• https://docs.tigase.net/tigase-server/master-snapshot/Administration_Guide/webhelp/_bouncycastle_being_used_for_starttls.html

[dirmgr]

The LDAP SDK does not now and will not ever require any third-party dependencies beside what's in Java SE (and currently limited to what's in Java SE 7). However, even if third-party dependencies were acceptable, the Bouncy Castle library is likely not one that would ever be used directly because of concerns around U.S. export control laws regarding strong encryption.

When you couple these restrictions with my strong negative opinions regarding the SCRAM SASL mechanisms as outlined above, it is extremely unlikely that the LDAP SDK will ever implement support for the SCRAM-x-PLUS SASL mechanisms. However, as I've pointed out above, the LDAP SDK does expose APIs for implementing support for SASL mechanisms in your own code, and you're certainly free to use the code I've already provided for implementing SCRAM support without channel binding (as long as you comply with the license for that code), along with whatever additional libraries you wish.

[Neustradamus]

@dirmgr: Thanks for your improvements of this year about SCRAM :)

But I hope one day about -PLUS variants directly...

[Neustradamus]

@dirmgr: Have you seen the RFC9266?

• Channel Bindings for TLS 1.3: https://datatracker.ietf.org/doc/html/rfc9266

For SCRAM-SHA3-512, it is possible too?

Thanks in advance.

Linked to:

• RFC 9266: Channel Bindings for TLS 1.3 support #134

[Neustradamus]

@dirmgr: Can you look for Channel Binding support?

There is a recent history with jabber.ru MITM and SCRAM-SHA-*-PLUS is the security solution!

Some sources about jabber.ru:

• https://notes.valdikss.org.ru/jabber.ru-mitm/
• https://snikket.org/blog/on-the-jabber-ru-mitm/
• https://www.devever.net/~hl/xmpp-incident
• https://blog.jmp.chat/b/certwatch

Thanks in advance.