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 SMTP and IMAP (e-mail), or XMPP (chat). For XMPP, supporting it is mandatory.
Contents
Motivation
Alice wants to log in to 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. And because 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 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 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.
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. All hash functions 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
Messages
RFC 5802 names four consecutive messages between server and client:
Salted password
The salted password
where
Proofs
The client and the server prove to each other they have the same
The proofs are calculated as follows:
where
Stored password
The stored password is equal to
For every user, the server only has to store the username and
In addition the server also needs to store the server key
Channel binding
The term channel binding describes the man-in-the-middle attack prevention strategy to 'bind' an 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. 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. An example use case of channel binding with SCRAM as application layer, could be with Transport Layer Security (TLS) as lower layer. While TLS protects from passive eavesdropping, it alone doesn't prevent man-in-the-middle attacks. For this, the endpoints need to assure their identities to each other, which is 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 attacks.
When a server supports channel binding, it adds the character sequence '-PLUS' to the advertised SCRAM algorithm name.