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.
Motivation Alice wants to log into Bob's server. She needs to prove she is who she claims to be. To solve 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, but that would 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. To address this, Bob has registered himself with a certificate authority (CA), which signed his certificate. Alice could solely rely on that signature system, but she knows it has weaknesses. To give her additional assurances 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 lower encryption channel is 'bound' to the higher application channel. Alice has been able to authenticate Bob, and Bob has authenticated Alice. Taken together, they have mutual authentication. DIGEST-MD5 already enabled mutual authentication, but it was often incorrectly implemented. 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 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 that to offer these login schemes to his users, he would have to store weakly hashed, un-salted passwords. He doesn't like that 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 Bob and Alice would then still face the problems described above. To solve this problem, they use SCRAM, where Bob can store the 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 are based on this value which both participants 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. Any hash function defined by the IANA can be used instead. As mentioned in the Motivation section, SCRAM uses the PBKDF2 mechanism, which increases the strength against brute-force attacks, when a data leak has happened on the server. Let H 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:
SaltedPassword = H(password, salt, iteration-count) = PBKDF2(HMAC, password, salt, iteration-count, output length of H).
Messages RFC 5802 names four consecutive messages between server and client:
client-first The client-first message consists of a GS2 header (comprising a channel binding flag, and optional name for authorization information), the desired username, and a randomly generated client nonce c-nonce. server-first The server appends to this client nonce its own nonce s-nonce, and adds it to the server-first message, which also contains a salt used by the server for salting the user's password hash, and an iteration count iteration-count. 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, proof. server-final The communication closes with the server-final message, which contains the server signature, verifier.
Proofs The client and the server prove to each other they have the same Auth variable, consisting of:
Auth = client-first-without-header + , + server-first + , + client-final-without-proof (concatenated with commas) More concretely, this takes the form:
= n=username,r=c‑nonce,[extensions,]r=c‑nonce‖s‑nonce,s=salt,i=iteration‑count,[extensions,]c=base64(channel‑flag,[a=authzid],channel‑binding),r=c‑nonce‖s‑nonce[,extensions] The proofs are calculated as follows:
ClientKey = HMAC(SaltedPassword, 'Client Key') ServerKey = HMAC(SaltedPassword, 'Server Key') ClientProof = p = ClientKey XOR HMAC(H(ClientKey), Auth) ServerSignature = v = HMAC(ServerKey, Auth) where the XOR operation is applied to byte strings of the same length, H(ClientKey) is a normal hash of ClientKey. 'Client Key' and 'Server Key' are verbatim strings. The server can authorize the client by computing ClientKey from ClientProof and then comparing H(ClientKey) with the stored value. The client can authorize the server by computing and comparing ServerSignature directly.
… excerpt ends here. Continue reading the full article.
