dequbed / rsasl

The Rust SASL framework
MIT License
12 stars 6 forks source link

`SCRAM-SHA512` and `SCRAM-SHA512-PLUS` support? #26

Closed TheWaWaR closed 2 months ago

TheWaWaR commented 1 year ago

Since ScramServer is a private struct, how do I add SCRAM-SHA512 and SCRAM-SHA512-PLUS support?

Or, do you have any plan to add those support?

In the code, I see you have tried to add sha512 support but why comment it later?

#[cfg(feature = "scram-sha-1")]
pub type ScramSha1Server<const N: usize> = ScramServer<sha1::Sha1, N>;
#[cfg(feature = "scram-sha-2")]
pub type ScramSha256Server<const N: usize> = ScramServer<sha2::Sha256, N>;
// #[cfg(feature = "scram-sha-2")]
// pub type ScramSha512Server<const N: usize> = ScramServer<sha2::Sha512, N>;
dequbed commented 1 year ago

Since ScramServer is a private struct, how do I add SCRAM-SHA512 and SCRAM-SHA512-PLUS support?

If you need support for SCRAM-SHA512 and SCRAM-SHA512-PLUS right now you could make use of the unstable_custom_mechanism feature in rsasl. There isn't a good example of that feature in this repo yet, but you can have a look at https://gitlab.com/fabinfra/fabaccess/bffh/-/blob/e35e2b7334823ea682a226a7bb5bd31da2291079/bffhd/authentication/fabfire/mod.rs for some guidance on how that feature can be used with rsasl-2.0.0.

Keep in mind that this feature opt out of semver stability and may change on minor version number changes for now, as I'm not sure if I have it right just yet and may need to add required methods to the Authentication trait.

Or, do you have any plan to add those support?

In the code, I see you have tried to add sha512 support but why comment it later?

I'm not opposed to adding support for SCRAM-SHA512(-PLUS) in rsasl proper, but I don't know of deployment of that mechanism or other implementations so I couldn't test my implementation and thus was reluctant to advertise support.

The latter also holds for SCRAM-ARGON2 and other custom variations of the SCRAM family. In general rsasl has so far been mostly focusing on IANA-registered 'COMMON' mechanism (i.e. the SCRAM variants listed here).

If you do have a different implementation you can verify against, please open a PR adding the support!

TheWaWaR commented 1 year ago

Thanks for your answer.

I just research for the possibility to add SCRAM-SHA512(-PLUS) to our product. In currently stage, I think use SCRAM-SHA256(-PLUS) is good enough.

However, since SHA-1 is considered insecure since 2005, so I just wonder why SCRAM-SHA-1(-PLUS) still marked as COMMON in that list.

dequbed commented 1 year ago

However, since SHA-1 is considered insecure since 2005, so I just wonder why SCRAM-SHA-1(-PLUS) still marked as COMMON in that list.

SHA-1 is specifically weak when used as a collision-resistant compression function — as is the case with e.g. digital signatures.

SCRAM does not use the underlying hash in that way, but instead uses it only via HMAC construction as KDF or MAC. HMAC's proof of security notably does not rely on collision-resistance of the hash function, and HMAC-SHA1 is not considered to be insecure when used as either of those two. It is in fact explicitly allowed by the same NIST recommendation that is phasing out SHA-1. (note that this is not universally the case, e.g. the German Federal Office for Information Security (BSI) only allows HMAC-SHA1 in special circumstances)