View source for Salted Challenge Response Authentication Mechanism

{{About|password authentication||Scram (disambiguation)}}

In cryptography, the '''Salted Challenge Response Authentication Mechanism''' ('''SCRAM''') is a family of modern, password-based [[challenge–response authentication]] mechanisms providing authentication of a user to a server. As it is specified for [[Simple Authentication and Security Layer]] (SASL), it can be used for password-based logins to services like [[LDAP]], [[HTTP]], [[SMTP]], [[POP3]], [[IMAP]] and [[JMAP]] ([[e-mail]]), [[XMPP]] (chat), or [[MongoDB]] and [[PostgreSQL]] (databases). For XMPP, supporting it is mandatory.<ref>{{Cite web |date=March 2011 |title=Extensible Messaging and Presence Protocol: For Confidentiality and Authentication with Passwords |url=https://datatracker.ietf.org/doc/html/rfc6120#section-13.8.3 |access-date=2023-08-04 |publisher=[[IETF]]}}</ref>

== Motivation ==
[[Alice and Bob|Alice]] wants to log into Bob's server. She needs to prove she is who she claims to be. For solving this authentication problem, Alice and Bob have agreed upon a password, which Alice knows, and which Bob knows how to verify.

Now Alice could send her password over an unencrypted connection to Bob in a clear text form, for him to verify. That would however make the password accessible to Mallory, who is wiretapping the line. Alice and Bob could try to bypass this by encrypting the connection. However, Alice doesn't know whether the encryption was set up by Bob, and not by Mallory by doing a [[man-in-the-middle attack]]. Therefore, Alice sends a hashed version of her password instead, like in [[CRAM-MD5]] or [[DIGEST-MD5]]. As it is a hash, Mallory doesn't get the password itself. As the hash is salted with a challenge, Mallory could use it only for one login process. However, Alice wants to give some confidential information to Bob, and she wants to be sure it's Bob and not Mallory.

For solving this, Bob has registered himself to a [[certificate authority]] (CA), which signed his certificate. Alice could solely rely on that signature system, but she knows it has [[certificate authority#CA compromise|weaknesses]]. To give her additional assurance that there is no man-in-the-middle attack, Bob creates a proof that he knows the password (or a salted hash thereof), and includes his certificate into this proof. This inclusion is called channel binding, as the [[OSI model|lower]] encryption channel is 'bound' to the higher application channel.

Alice then has an authentication of Bob, and Bob has authentication of Alice. Taken together, they have [[mutual authentication]]. DIGEST-MD5 already enabled mutual authentication, but it was often incorrectly implemented.<ref>{{Cite web |last=Kurt Zeilenga |date=19 May 2010 |title=SCRAM in LDAP Better Password-based Authentication |url=https://people.apache.org/~elecharny/ldapcon/Kurt%20Zeilenga-paper.pdf |access-date=2023-08-04}}</ref><ref>{{Cite web |last=Simon Josefsson |date=2011-02-06 |title=GNU Network Security Labyrinth |url=https://josefsson.org/talks/gnu-network-security-labyrinth.pdf |access-date=2023-08-04}}</ref>

When Mallory runs a man-in-the-middle attack and forges a CA signature, she could retrieve a hash of the password. But she couldn't impersonate Alice even for a single login session, as Alice included into her hash the encryption key of Mallory, resulting in a login-fail from Bob. To make a fully transparent attack, Mallory would need to know the password used by Alice, or the secret encryption key of Bob.

Bob has heard of data breaches of server databases, and he decided that he doesn't want to store the passwords of his users in clear text. He has heard of the CRAM-MD5 and DIGEST-MD5 login schemes, but he knows, for offering these login schemes to his users, he would have to store weakly hashed, un-salted passwords. He doesn't like the idea, and therefore he chooses to demand the passwords in plain text. Then he can hash them with secure hashing schemes like [[bcrypt]], [[scrypt]] or [[PBKDF2]], and salt them as he wants. However, then Bob and Alice would still face the problems described above. To solve this problem, they use SCRAM, where Bob can store his password in a salted format, using PBKDF2. During login, Bob sends Alice his salt and the iteration count of the PBKDF2 algorithm, and then Alice uses these to calculate the hashed password that Bob has in his database. All further calculations in SCRAM base on this value which both know.

== Protocol overview ==
Although all clients and servers have to support the [[SHA-1]] hashing algorithm, SCRAM is, unlike [[CRAM-MD5]] or [[DIGEST-MD5]], independent from the underlying hash function.<ref>{{Cite web |date=July 2010 |title=Salted Challenge Response Authentication Mechanism (SCRAM) SASL and GSS-API Mechanisms: SCRAM Mechanism Names |url=https://datatracker.ietf.org/doc/html/rfc5802#section-4 |access-date=2023-08-04 |publisher=IETF}}</ref> All hash functions defined by the IANA can be used instead.<ref>{{Cite web |date=2019-12-16 |title=Hash Function Textual Names |url=https://www.iana.org/assignments/hash-function-text-names/hash-function-text-names.xhtml |access-date=2023-08-04 |publisher=[[IANA]]}}</ref> As mentioned in the Motivation section, SCRAM uses the [[PBKDF2]] mechanism, which increases the strength against [[Password cracking|brute-force attacks]], when a data leak has happened on the server. Let <code>H</code> be the selected hash function, given by the name of the algorithm advertised by the server and chosen by the client. 'SCRAM-SHA-1' for instance, uses SHA-1 as hash function.

=== Password-based derived key, or salted password ===
The client derives a key, or salted password, from the password, a salt, and a number of computational iterations as follows:
: <code>''SaltedPassword'' = H(''password'', ''salt'', ''iteration-count'') = [[PBKDF2]]([[HMAC]], ''password'', ''salt'', ''iteration-count'', ''output length of ''H)</code>.

=== Messages ===
RFC 5802 names four consecutive messages between server and client:

; ''client-first'': The ''client-first'' message consists of a [[Simple Authentication and Security Layer#SASL mechanisms|GS2]] header (comprising a channel binding flag, and optional name for authorization information), the desired <code>''username''</code>, and a randomly generated client nonce <code>''c-nonce''</code>.
; ''server-first'': The server appends to this client nonce its own nonce <code>''s-nonce''</code>, and adds it to the ''server-first'' message, which also contains a <code>''salt''</code> used by the server for salting the user's password hash, and an iteration count <code>''iteration-count''</code>.
; ''client-final'': After that the client sends the ''client-final'' message containing ''channel-binding'', the GS2 header and channel binding data encoded in base64, the concatenation of the client and the server nonce, and the client proof, <code>''proof''</code>.
; ''server-final'' : The communication closes with the ''server-final'' message, which contains the server signature, <code>''verifier''</code>.

=== Proofs ===
The client and the server prove to each other they have the same <code>''Auth''</code> variable, consisting of:
:<code>''Auth'' = ''client-first-without-header'' + , + ''server-first'' + , + ''client-final-without-proof''</code> (concatenated with commas)

More concretely, this takes the form:
:<code>= n=''username'',r=''c{{nbh}}nonce'',[''extensions'',]r=''c{{nbh}}nonce''‖''s{{nbh}}nonce'',s=''salt'',i=''iteration{{nbh}}count'',[''extensions'',]c=base64(''channel{{nbh}}flag'',[a=''authzid'']<!--mandatory comma repetition intended-->,''channel{{nbh}}binding''),r=''c{{nbh}}nonce''‖''s{{nbh}}nonce''[,''extensions'']</code>

The proofs are calculated as follows:

:<code>''ClientKey'' = HMAC(''SaltedPassword'', 'Client Key')</code>
:<code>''ServerKey'' = HMAC(''SaltedPassword'', 'Server Key')</code>
:<code>''ClientProof'' = ''p'' = ''ClientKey'' XOR HMAC(H(''ClientKey''), ''Auth'')</code>
:<code>''ServerSignature'' = ''v'' = HMAC(''ServerKey'', ''Auth'')</code>

where the [[XOR]] operation is applied to byte strings of the same length, <code>H(''ClientKey'')</code> is a normal hash of <code>''ClientKey''</code>. <code>'Client Key'</code> and <code>'Server Key'</code> are verbatim strings.

The server can authorize the client by computing <code>ClientKey</code> from <code>ClientProof</code> and then comparing <code>H(ClientKey)</code> with the stored value.

The client can authorize the server by computing and comparing <code>ServerSignature</code> directly.

=== Stored password ===
The server stores only the username, <code>''salt''</code>, <code>''iteration-count''</code>, <code>H(''ClientKey'')</code>, <code>''ServerKey''</code>. The server has transient access to <code>''ClientKey''</code> as it is recovered from the client proof, having been encrypted with <code>H(''ClientKey'')</code>.

The client needs only the <code>''password''</code>.

=== Channel binding ===
The term ''channel binding'' describes the [[man-in-the-middle attack]] prevention strategy to 'bind' an [[OSI model|application layer]], which provides mutual authentication, to a lower (mostly encryption) layer, ensuring that the endpoints of a connection are the same in both layers. There are two general directions for channel binding: ''unique'' and ''endpoint'' channel binding. The first ensures that a specific connection is used, the second that the endpoints are the same.

There are several channel binding types, where every single type has a ''channel binding unique prefix''.<ref>{{Cite web |date=November 2007 |title=On the Use of Channel Bindings to Secure Channels: Registration Procedure |url=https://datatracker.ietf.org/doc/html/rfc5056#section-7.1 |access-date=2023-08-04 |publisher=IETF}}</ref> Every channel binding type specifies the content of the ''channel binding data'', which provides unique information over the channel and the endpoints. For instance, for the ''tls-server-end-point'' channel binding, it is the server's TLS certificate.<ref>{{Cite web |date=July 2010 |title=Channel Bindings for TLS: The 'tls-server-end-point' Channel Binding Type |url=https://datatracker.ietf.org/doc/html/rfc5929#section-4 |access-date=2023-08-04 |publisher=IETF}}</ref> An example use case of channel binding with SCRAM as application layer, could be with [[Transport Layer Security]] (TLS) as lower layer. TLS protects from passive eavesdropping, as the communication is encrypted. However, if the client doesn't authenticate the server (e.g. by verifying the server's certificate), this doesn't prevent man-in-the-middle attacks. For this, the endpoints need to assure their identities to each other, which can be provided by SCRAM.

The ''gs2-cbind-flag'' SCRAM variable specifies whether the client supports channel binding or not, or thinks the server doesn't support channel binding, and ''c-bind-input'' contains the ''gs2-cbind-flag'' together with the ''channel binding unique prefix'' and the ''channel binding data'' themselves.

Channel binding is optional in SCRAM, and the ''gs2-cbind-flag'' variable prevents from [[downgrade attack]]s.

When a server supports channel binding, it adds the character sequence '-PLUS' to the advertised SCRAM algorithm name.

== Strengths ==
* Strong password storage: When implemented in a right way, the server can store the passwords in a [[Salt (cryptography)|salted]], iterated hash format, making [[Password cracking|offline attacks]] harder, and decreasing the impact of database breaches.<ref>{{Cite web |date=19 May 2010 |title=SCRAM: A New Protocol for Password Authentication |url=https://www.isode.com/whitepaper/scram-a-new-protocol-for-password-authentication/ |access-date=2024-05-27}}</ref>
* Simplicity: Implementing SCRAM is easier<ref name="ayena-digest">{{Cite web |last=Tobias Markmann |date=2 December 2009 |title=Scram DIGEST-MD5! |url=https://ayena.de/blog/scram-digest-md5/ |url-status=dead |archive-url=https://web.archive.org/web/20210417232208/https://ayena.de/blog/scram-digest-md5/ |archive-date=2021-04-17 |access-date=2023-08-04}}</ref> than DIGEST-MD5.<ref>{{Cite web |date=July 2011 |title=RFC6331: Moving DIGEST-MD5 to Historic |url=https://datatracker.ietf.org/doc/html/rfc6331 |access-date=2023-08-04 |publisher=IETF}}</ref>
* International interoperability: the RFC requires [[UTF-8]] to be used for usernames and passwords, unlike CRAM-MD5.<ref name="ayena-digest" /><ref>{{Cite web |date=November 2008 |title=CRAM-MD5 to Historic |url=https://datatracker.ietf.org/doc/html/draft-ietf-sasl-crammd5-to-historic-00 |access-date=2023-08-04 |publisher=IETF}}</ref>
* As only the salted and hashed version of a password is used in the whole login process, and the salt on the server doesn't change, a client storing passwords can store the hashed versions, and not expose the clear text password to attackers. Such hashed versions are bound to one server, which makes this useful on password reuse.<ref>{{Cite web |last=Tobias Markmann |date=2023-08-04 |title=Sleep Tight at Night Knowing That Your Passwords Are Safe |url=http://ayena.de/blog/sleep-tight-at-night-knowing-that-your-passwords-are-safe/ |url-status=dead |archive-url=https://web.archive.org/web/20210417234209/http://ayena.de/blog/sleep-tight-at-night-knowing-that-your-passwords-are-safe/ |archive-date=2021-04-17}}</ref>

== References ==
{{reflist|colwidth=30em}}

== External links ==
* {{IETF RFC|5802|link=no}}, Salted Challenge Response Authentication Mechanism (SCRAM) SASL and GSS-API Mechanisms
* {{IETF RFC|5803|link=no}}, Lightweight Directory Access Protocol (LDAP) Schema for Storing Salted Challenge Response Authentication Mechanism (SCRAM) Secrets
* {{IETF RFC|6120|link=no}}, Extensible Messaging and Presence Protocol (XMPP): Core
* {{IETF RFC|6331|link=no}}, Moving DIGEST-MD5 to Historic
* {{IETF RFC|7677|link=no}}, SCRAM-SHA-256 and SCRAM-SHA-256-PLUS: Simple Authentication and Security Layer (SASL) Mechanisms
* {{IETF RFC|7804|link=no}}, Salted Challenge Response HTTP Authentication Mechanism
* {{IETF RFC|8600|link=no}}, Using Extensible Messaging and Presence Protocol (XMPP) for Security Information Exchange
* {{IETF RFC|8621|link=no}}, The JSON Meta Application Protocol (JMAP) for Mail
* {{IETF RFC|9051|link=no}}, Internet Message Access Protocol (IMAP) - Version 4rev2
* {{IETF RFC|9266|link=no}}, Channel Bindings for TLS 1.3
* [https://datatracker.ietf.org/doc/html/draft-ietf-sasl-crammd5-to-historic-00 draft-ietf-sasl-crammd5-to-historic-00] & [https://datatracker.ietf.org/doc/html/draft-zeilenga-luis140219-crammd5-to-historic-00 draft-zeilenga-luis140219-crammd5-to-historic-00], CRAM-MD5 to Historic
* [https://datatracker.ietf.org/doc/html/draft-melnikov-scram-sha-512 draft-melnikov-scram-sha-512], SCRAM-SHA-512 and SCRAM-SHA-512-PLUS Simple Authentication and Security Layer (SASL) Mechanisms
* [https://datatracker.ietf.org/doc/html/draft-melnikov-scram-sha3-512 draft-melnikov-scram-sha3-512], SCRAM-SHA3-512 and SCRAM-SHA3-512-PLUS Simple Authentication and Security Layer (SASL) Mechanisms
* [https://datatracker.ietf.org/doc/html/draft-melnikov-scram-bis draft-melnikov-scram-bis], Salted Challenge Response Authentication Mechanism (SCRAM) SASL and GSS-API Mechanisms
* [https://datatracker.ietf.org/doc/html/draft-ietf-kitten-scram-2fa draft-ietf-kitten-scram-2fa], Extensions to Salted Challenge Response (SCRAM) for 2 factor authentication
* [https://datatracker.ietf.org/doc/html/draft-melnikov-sasl2 draft-melnikov-sasl2], Extensible Simple Authentication and Security Layer (SASL)
* [https://github.com/scram-sasl/info/issues/1 State of Play], more details about SCRAM SASL support

[[Category:Cryptographic protocols]]