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

[Neustradamus]

"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]".

There is only SCRAM-SHA-1, can you add support for?

• 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:

• SCRAM-SHA-1-PLUS support #35
• State of Play scram-sasl/info#1

[COM8]

SCRAM-SHA-256 support should be easy to add.
But the PLUS versions take a little bit more work to be done.

Thanks for the RFC links!

[Neustradamus]

@COM8 Thanks for all commits that you have done about SCRAM-SHA-256!
I can not wait for -PLUS variant ^^

[Neustradamus]

It is possible to add for 512 too?

[COM8]

Hmmm, well it would be really easy to add support for the 512 variants too, but I don't think it's that useful since everything using SHA-1 is basically deprecated at this point (Reference). It also is not proven, that it provides more security in any way (If the mechanism is broken why should increasing the iterations count improve security?).

An other point is: You can use SCRAM-SHA-1 as auth method and send an iteration count >= 4096 to your clients because the "number" only handles the min iterations count that is required.
So I see this as a responsibility of the server software you are using, setting the "iterations count" to an appropriate value.

Do you know any server that actually supports the 256 and 512 versions?

Let me think about it for a couple of days and I will come back to it then.

Thanks for your suggestion!

[Neustradamus]

List here: scram-sasl/info#1

[COM8]

OK I will add support for it, since it's quiet easy to do. Do you have any RFC for it? Can't find any.

[Neustradamus]

Only RFCs cited before.
But a lot of softwares (cited previously and others) use other possibilities too...

[Neustradamus]

From 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]".

[COM8]

If this is the TLDR out of the paper - sure yes, that's true 😄 .

[Neustradamus]

XMPP servers remove the old history unsecured MD5 support, any news on it?

[COM8]

Nope. I've never actually implemented MD5 since it's not save since ages.
Currently the following mechanisms are supported:

• PLAIN
• SHA256
• SHA1

[Neustradamus]

Can you add other SCRAM possibilities?
To have 1/224/256/384/512?
And for -PLUS variants, complicated?
Some clients already supported it, look the link in main publication :)

[COM8]

The non PLUS variants are easy to add, but for the PLUS variants I need to pass the server certificate to the mechanism which is not possible right not.
It requires quiet a bit of work since I have to reengineer the way the connection gets handled.
Perhaps add a connection context of some sorts, where I store information like the cert.

[COM8]

@Neustradamus, Thanks.

[Neustradamus]

@COM8: Can you add 512 like others?

[COM8]

512 as I can see it, yes. But the PLUS variants are not.

[Neustradamus]

SCRAM-SHA-512, and maybe SCRAM-SHA3-512 too?

Yes I know, PLUS variants is different...

[COM8]

Don't know right now. I have to have a look into it.

[COM8]

Just a small update from my side on this.
I fixed the SCRAM-SHA-256 implementation #153 .
SCRAM-SHA-512 is currently not possible for me, since c# on UWP currently does not support SHA3 hashing with Rfc2898DeriveBytes. For this I have to implement my own PBKDF2 password-based key derivation function which is currenly out of my scope.

[Neustradamus]

@COM8: Are you sure that SCRAM-SHA-512 can not be added?

And SCRAM-SHA3-512 too?

Linked to:

• https://tools.ietf.org/html/draft-melnikov-scram-sha-512
• https://tools.ietf.org/html/draft-melnikov-scram-sha3-512
• https://datatracker.ietf.org/doc/html/draft-melnikov-scram-bis