SCRAM with Modular Crypt Format (SCRAM-MCF)

Introduction SCRAM as defined in and its SHA-256 variant in is widely deployed (PostgreSQL, MongoDB, Kafka, SASL libraries, etc.). Its only key derivation function is PBKDF2-HMAC-SHA-1 or PBKDF2-HMAC-SHA-256. PBKDF2 is no longer considered state-of-the-art against GPU/ASIC-based password cracking. Modern password hashing algorithms (Argon2 – winner of the 2015 Password Hashing Competition, SCrypt, bcrypt) are memory-hard and far more resistant to parallel brute-force attacks. However, replacing SCRAM entirely with a new mechanism is unnecessary: the core proof-of-possession construction of SCRAM is excellent. Only the key derivation step needs to become negotiable. This document defines the smallest possible standards-compliant extension that achieves exactly that.

Conventions and Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here. The term "Modular Crypt Format" (MCF) refers to the de-facto standard string format used by crypt(3), Passlib, Spring Security, and most modern password hashing libraries. Examples:

SCRAM-MCF Extension

Client Capability Advertisement A client that implements SCRAM-MCF MUST include the attribute mcf-support=1 in the reserved extension field of the client-first-message when using any SCRAM mechanism that supports this extension. Example (client-first-message): n,,n=user,r=fyko+d2lbbFgONRv9qkxdawL,mcf-support=1 Clients that do not send mcf-support=1 MUST be treated exactly as in the original SCRAM algorithm (legacy clients). They MUST NOT support the mcf= attribute if they did not send mcf-support=1 first.

Server-first-message Changes A server that receives mcf-support=1 and wishes to use a modern KDF MUST respond with the attribute mcf= instead of i= and s=. The value of mcf= is the full MCF identifier string up to but not including the final stored hash part, encoded as base-64. In other words: everything up to and including the base64-encoded salt and its trailing $ character (if any), then converted to base-64. The MCF identifier MUST be converted to base-64, to ensure no commas signs appear in the attribute value. Valid examples of MCF identifiers: $argon2id$v=19$m=65536,t=2,p=4$z8e0jsE2kz7z6uL0m4zZ6Q$ $scrypt$ln=16,r=8,p=1$z8e0jsE2kz7z6uL0m4zZ6Q$ $2a$06$m0CrhHm10qJ3lXRY.5zDGO Values transmitted as mcf= attribute, after base-64 encoding: mcf=JGFyZ29uMmlkJHY9MTkkbT02NTUzNix0PTIscD00JHo4ZTBqc0Uya3o3ejZ1... mcf=JHNjcnlwdCRsbj0xNixyPTgscD0xJHo4ZTBqc0Uya3o3ejZ1TDBtNHpaNlEk mcf=JDJhJDA2JG0wQ3JoSG0xMHFKM2xYUlkuNXpER08= Backward compatibility fallback: If the server cannot or does not want to use MCF, it simply omits mcf= and sends the normal i= and s= attributes.

Client Processing Rules

If the server-first-message contains mcf=, the client MUST ignore any i= and s= attributes and MUST use the specified MCF string, after proper base-64 decoding, to derive SaltedPassword exactly as if it were calling the standard password-to-key function of that algorithm with the cleartext password and the MCF parameters/salt.
The full encoded output of this MCF KDF, including its identifier, parameters, salt and checksum, MUST become the SaltedPassword as in Section 3.
The rest of the protocol (ClientKey, ServerKey, AuthMessage, ClientProof, etc.) is unchanged.
The H() and HMAC() functions used to compute the client and server proofs MUST follow the SASL negotiation, e.g. SHA-256 and HMAC-SHA-256 for "SCRAM-SHA-256" or SHA-512 and HMAC-SHA-512 for "SCRAM-SHA-512".
If the client does not recognize or support the MCF identifier, it MUST respond with a SASL/HTTP error (e.g., "invalid-parameters").

SCRAM-MCF Algorithm Overview The following is a description of the algorithms used in a full, uncompressed SASL SCRAM-MCF authentication exchange. The rest of these messages is defined in Section 7.

Server Storage Recommendation Servers MUST store the MCF prefix string (identifier + parameters + salt) for each user. For security reasons, the MCF checksum part MUST NOT be persisted; instead, the SCRAM-derived StoredKey and ServerKey MUST be stored. Servers MAY store and accept other SCRAM hashes (e.g., SCRAM-SHA-1 or SCRAM-SHA-256) for backward compatibility. But restricting to the safest algorithms (like SCRAM-MCF) is strongly recommended.

Formal ABNF Changes (augmented from RFC 5802)

Security Considerations

Preservation of the SCRAM Proof Construction In respect to the standard SCRAM mechanism, this SCRAM-MCF extension could be evaluated as such:

The extension preserves channel binding, proof-of-possession, and mutual authentication exactly as in SCRAM.
Memory-hard KDFs dramatically increase the cost of offline dictionary attacks.
Because the KDF identifier and parameters are sent in the clear (as in standard SCRAM with i=), no new information is leaked to an eavesdropper.
Thanks to the MCF registration mechanism, this SCRAM-MCF pattern was designed to be future-proof.
Clients and servers MUST enforce minimum work factors (e.g., reject Argon2 with m<32 MiB or t<2) to avoid downgrade attacks if the server is compromised.
Weaker "SCRAM-SHA-1" MUST be rejected when used with the mcf= extension.

Using MCF-Derived Outputs as HMAC Keys As defined above, ClientKey and ServerKey are computed using HMAC() on the MCF output. The length and structure of this value differ from PBKDF2, as used in classic SCRAM. HMAC constructions (including HMAC-SHA-256 and HMAC-SHA-512 refered by this document) are provably secure even when the supplied key is long or non-uniform. Per Bellare, Canetti, and Krawczyk (1997; 2006), HMAC guarantees pseudorandomness provided that:

keys longer than the hash function block size are reduced by hashing (as mandated by HMAC), and
keys of arbitrary internal structure are permitted.

Thus, MCF outputs — even if longer than a SHA-2 block — are acceptable and safe HMAC keys. Because memory-hard KDFs generate outputs indistinguishable from random to an attacker lacking the password, the resulting SaltedPassword is at least as strong as the PBKDF2-derived SaltedPassword in classic SCRAM. Therefore, replacing PBKDF2 output with memory-hard KDF output does not weaken the HMAC-based authentication proofs of SCRAM.

IANA Considerations This document requests IANA registration of the SASL/GS2 extension attribute mcf-support and the server-first-message attribute mcf. No new SASL mechanism name ("SCRAM-MCF-*") needs to be registered. The existing names "SCRAM-SHA-256", "SCRAM-SHA-256-PLUS", "SCRAM-SHA-512", etc. continue to identify the underlying H() and HMAC() functions used for the proof calculation.

Acknowledgments The idea of using Modular Crypt Format inside a SCRAM-like flow was first implemented by the author in the Synopse mORMot 2 Framework in 2025 and standardized as the wire-level extension described in this document. The author would like to thank the PostgreSQL, MongoDB, and SASL communities for their prior art and feedback on modernizing password hashing in authentication protocols.

SCRAM Authentication Exchange This is a simple example of a SCRAM-SHA-256 authentication exchange when the client doesn't support channel bindings (username 'user' and password 'pencil' are used, with SCrypt MCF hashing): The corresponding MCF prefix string is "$scrypt$ln=4,r=8,p=1$QNx4N454ppMeKmDjxyrhsh7Q/PYBQw$", which is base-64 encoded in the mcf= attribute above.