Salted Challenge Response Authentication Mechanism (SCRAM)

The Salted Challenge Response Authentication Mechanism (SCRAM) is a protocol used to support password-based authentication without sending the password itself.

SCRAM uses cryptographic hashing techniques and a server-generated ‘salt’ to create a hash on both client and server sides. This hash is then compared to confirm the authentication, ensuring mutual authentication without the password or password hash being transmitted.

This makes SCRAM resistant to various types of attacks, including eavesdropping and dictionary attacks. SCRAM is commonly used in Internet protocols like XMPP, IMAP, SMTP, and is the default authentication mechanism for MongoDB.

How SCRAM works

SCRAM authentication works through an interactive conversation between a client (user) and server. It involves several steps:

1. SCRAM session begins with the client sending a username and a client ‘nonce’ – a unique, random number, to the server. This is the “client-first” message.
2. In response, the server sends back a ‘nonce’ of its own (appended to the client nonce), along with a ‘salt’ (a random data that is used as an additional input to a one-way function that hashes data or password), and an iteration count. This constitutes the “server-first” message.
3. The client then uses these values along with its password to compute a ‘Client Proof’ and sends it back to the server, along with a ‘channel binding’ information. This is the “client-final” message.
4. The server then validates the ‘Client Proof’ using the stored iteration count, salt, and the original password’s hash.  If it validates, the server will then generate a ‘Server Signature’ and send it back to the client. This is the “server-final” message.
5. Finally, the client validates the ‘Server Signature’.

If both ‘Client Proof’ and ‘Server Signature’ validations are successful, the client and server have mutually authenticated. 

This process is designed to protect password-based authentication from eavesdropping and man-in-the-middle attacks while also providing mutual authentication. SCRAM can function with any hash function and is usually used with Transport Layer Security (TLS) for an extra layer of security. It can also incorporate channel binding to bind the authentication to a lower encryption layer.

Why use SCRAM?

Organizations use SCRAM authentication for numerous reasons:

Higher Security

SCRAM offers a higher level of security by storing hashed passwords, instead of plain ones, on the server. This means that even in case of a data breach, the attacker won’t be able to see the actual passwords.

Protection against Replay Attacks

SCRAM helps guard against replay attacks, in which an attacker intercepts and reuses authentication messages. It does not allow previously intercepted authentication messages to be reused illegitimately.

Defense Against Hacking

SCRAM helps to adopt different hashing algorithms when they evolve, which makes it harder to break the encryption.

Resistance to Brute force Attacks

SCRAM uses an iteration value which can be set to a high number making the brute force attack computationally very expensive and impractical.

Prevention of Man-in-the-middle Attacks

SCRAM’s feature “channel binding” can provide additional protection against man-in-the-middle attacks, which occur when an attacker secretly intercepts and potentially alters the communication between two parties who believe they are directly communicating with each other.

Offloading Computation Cost

SCRAM shifts the computation cost of password hashing from the server to the client. This can prevent servers from being overwhelmed in a potential distributed denial of service (DDoS) attack.

Separation of Concerns

By using SCRAM, an organization can delegate the handling of cleartext credentials to a dedicated secrets-management service, minimizing exposure and possibly avoiding breaches. It’s easier to ensure security when responsibilities are clearly divided.

Coexistence with Other Protocols

SCRAM is designed in a way that it can coexist well with other authentications protocols, which is crucial for organizations with complex systems that include legacy parts.

The recommendation, however, is for organizations to still use SCRAM authentication in conjunction with secure transport layers such as TLS for increased security.

Strengths of SCRAM

• Strong password storage: SCRAM enables servers to store passwords in a salted, iterated hash format that makes offline attacks more difficult and lessens the impact of database breaches.
• Simplicity: SCRAM is easier to implement than other authentication methods like DIGEST-MD5.
• International interoperability: The RFC for SCRAM requires the use of UTF-8 for usernames and passwords, unlike CRAM-MD5.
• Client Password Protection: Since only the salted and hashed version of a password is used in the entire login process, and the salt on the server doesn’t change, a client storing passwords can store the hashed versions. This means the client doesn’t expose clear text passwords to attackers. 
• Resistance to Attacks: SCRAM offers stronger protection against replay attacks, man-in-the-middle attacks, and dictionary attacks.
• Separation of concerns: In SCRAM authentication, handling of cleartext credentials can be delegated to a dedicated secrets-management service, minimizing the exposure of the credentials and reducing the impact of database compromises.
• Offloading of Computation Cost: SCRAM offloads the computationally expensive task of encryption to the client, in turn offering additional protection against DDoS attacks by preventing a CPU overload on the server.
• Cryptography Aging: SCRAM is designed to be used with any hash algorithm, allowing it to evolve with improving cryptography.

Weaknesses of SCRAM

• Client-side Load: SCRAM offloads the task of encryption to the client. This means that the clients, which are mostly application servers, have to deal with the computational load of producing the proof of identity for each authentication. This can potentially affect the performance of client applications.
• Vulnerability with Compromised Database: In the event of a compromised database, if the authentication exchange is intercepted, an imposter can pose as the client for that server. This is the primary weakness of SCRAM. This threat underlines the need to protect the secret database carefully and to use Transport Layer Security (TLS).
• Requirement of TLS for Optimum Security: While SCRAM significantly improves security for password-based authentication, to achieve the best security, it should be used with TLS or another data confidentiality mechanism, which may add an extra layer of complexity.
• Need for Strict Password Policies: The effectiveness of SCRAM is dependent on the enforcement of rigorous password policies by the system. Inadequate password policies could still lead to vulnerabilities, such as brute force attacks, especially in the case of a compromised database.
• May Require Changes in Client Applications: Using SCRAM may mean that changes need to be made to client applications, such as limiting the number of connections in the application’s connection pool or limiting the number of concurrent transactions the client can issue.