SCRAM Authentication: Overcoming Mock Testing Challenges

In the vast landscape of cybersecurity, authentication stands as the guardian of digital fortresses, ensuring that only the right individuals gain access to sensitive information and services. Imagine you're at the entrance of a top-secret facility, and you need to prove your identity to the security personnel. In the digital realm, this is precisely what authentication mechanisms do – they verify your identity before granting access.
When it comes to databases, making sure that the right programs have access is super important for keeping things safe and organised. At first, I thought databases might use a method called JWT tokens for this because it's popular and strong for security. However, I found out that there are different ways of authentication based on the connection state.

Token Based Authentications: Token-based authentication is a method where users or applications receive a special "token" after initial authentication. This token is then used for further requests without repeatedly verifying credentials for each new connection.
Due to this property, it is used in the Stateless Services (like REST APIs, SSO, etc)
Connection oriented Authentications: It is a method where users authenticates with the credentials for each connection or session. It is typically used in scenarios where a continuous connection or session is established between the client and server (like Databases, SSH).

In this blog post, we will explore how to mock SCRAM authentication in a testing environment. Before we dive into the details, let's first understand what SCRAM (Salted Challenge Response Authentication Mechanism) is and how it is used by databases like MongoDB.

What is SCRAM authentication

SCRAM, which stands for "Salted Challenge Response Authentication Mechanism," is a powerful challenge-based authentication method that follows the SASL (Simple Authentication and Security Layer) framework. SASL is designed to provide a framework for authentication and security without exposing sensitive credentials like passwords during the authentication process. This helps with several important aspects of authentication and security in the digital world:

Password Protection: In SCRAM, the password is not shared between the client and server which ensures the security of user password. This also prevents from the MITM attacks.
Protection Against Credential Attacks: SCRAM is resistant to common credential-based attacks such as brute force and dictionary attacks. The salted and hashed passwords, along with challenge-response mechanisms, add a layer of complexity that makes it challenging for attackers to guess passwords.
Confidentiality: SCRAM ensures the confidentiality of sensitive data during authentication. By using cryptographic techniques and secure channels, it prevents unauthorised entities from eavesdropping on authentication attempts.
Secure Access Control: SCRAM plays a crucial role in access control, ensuring that only authorised users or applications can interact with a system or database.

There is a good example on wikipedia describing scram. here

How SCRAM authentication works

After exploring what SCRAM is and understanding its purpose, it's natural to wonder how it functions and ensures all the necessary properties for ideal authentication in database environments.

In SCRAM authentication, the client and server securely establish their identities without the need to exchange the user password. This is achieved by generating and validating cryptographic proofs. These proofs are created using robust cryptographic algorithms, such as HMAC and SHA-hashing. This method ensures that even if network packets are intercepted by an intruder, the password remains undecipherable.
As the generation and validation of proofs in SCRAM authentication rely on randomly generated nonces by the client and server, it ensures robust security against potential intruders. The key factor here is that for each new connection, a unique nonce is generated and associated with it. This dynamic and one-time use of nonces effectively mitigates the risk of packet capture leading to unauthorised access, enhancing the overall security of the communication process.

Here is a detailed flow of communication for SCRAM authenticaton.

Challenges for mocking SCRAM Auth

In a test environment, mocking libraries need to bypass authentication simply by returning a message indicating successful authentication. However, SCRAM introduces a more complex scenario. In SCRAM, the client not only authenticates itself but also verifies the server's identity, adding an additional layer of security. This dual-verification process presents a significant hurdle for mocking tools like Keploy, an API testing tool designed to capture and replay network data. Due to SCRAM's complex nature, these libraries often experience Auth failure error like:

Exception authenticating MongoCredential{mechanism=SCRAM-SHA-1, userName='USER', source='ADMIN', password=<hidden>, mechanismProperties=<hidden>}; nested exception is com.mongodb.MongoSecurityException

Upon debugging the network packets, we've identified key insights. Attached below are the pertinent packet details for reference:

# SaslStart request. Here, r is the client nonce.
n,,n=root,r=hjO1c6p6PaNbeDUGhn/Jak3FFuUZQBxN1xmOeWr5L1c=

# The mocked SaslStart response. Here, r is the client/server nonce.
r=cjr1a0k0KanfoMMNkr/LaedRRtTQUBxM4fe3tuc6K1d=/igGE0M3BBiDmR/et9DN4cOR+CoNtHxs,s=ZPGEqaD8ImD95Vt3c1uuVQkImxrntgG4Wjh37Q==,i=15000

In the mechanism under discussion, the r key plays a crucial role in transmitting nonces within the payload. During the process, the client initiates the interaction by sending a new client nonce within the request. Subsequently, it receives a combined client/server nonce, along with the salt and iteration count, in the SaslStart response. However, a notable issue arises here: the client nonce often does not match in the response payload of SaslStart. This mismatch is a critical point of concern, as it can disrupt the intended flow of the SaslContinue authentication cycle because client and server proof depends on the nonces.

Nonce Syncing: A Quick Fix for Successful auth

To bypass the nonce mismatch issue during SCRAM authentication in Keploy tests, a straightforward solution is to update the client nonce directly in the SaslStart response payload. This adjustment ensures that the client's nonce matches the server's, leading to successful authentication. Attaching the pseudo code:

func (saslStartRequest, saslStartResponse string) {
    expectedNonce, err := extractClientNonce( saslStartRequest )

    actualNonce, err := extractClientNonce( saslStartRequest )

    // Since, the nonce are randomlly generated string. so, each session have unique nonce.
    // Thus, the mocked server response should be updated according to the current nonce
    return strings.Replace( saslStartResponse, expectedNonce, actualNonce, -1), nil
}

Here is the code in production to update client nonce.

After implementing the quick fix of replacing the client nonce, we anticipated a smooth resolution. However, the error persisted, leading us to delve deeper into the problem. Further investigation required debugging the client driver, where we uncovered a critical issue: the server verification was failing on the client side.

Final step: Correct Server Proof Generation

In tackling SCRAM authentication issues with Keploy, the critical final step is ensuring the correct generation of server proof. This is essential for successful authentication, especially with how the client side works.

Client-Side Verification: The client uses the combined client/server nonce to verify the server. The method to generate the server proof, which is key to this verification, is straightforward yet precise.
Why Authentication Fails: Our tests showed that authentication failures were mainly due to the mismatch between the recorded server proof and the new nonces. Each new nonce combination requires a unique server proof, and if they don't match, authentication fails.
Fixing the Issue: The solution is simple: generate a new server proof for each new set of nonces. This means moving away from using a fixed, recorded proof to creating a new proof every time, based on the current nonces. This change solves the authentication problems and ensures that the client can successfully verify the server each time, making the process more secure and reliable.

The image below provides a detailed description of the formula used in generating server proofs:

Here, is the code in production for generating the server proof in SaslContinue

Hurray! Our fixes worked – authentication is now a smooth success in our test environment! 🎉🎊

Conclusion

To sum up our exploration of SCRAM authentication:

SCRAM Auth Insights: We've learned how SCRAM auth secures user verification without revealing passwords, a smart way to safeguard user credentials.
Mocking Library Challenges: Mocking tools (like Keploy), reliant on network packets, face hurdles with SCRAM due to its dynamic and secure nature.
Solution for Testing: To successfully test with mocking libraries, it's essential to configure them with the user's password. This allows for generating accurate server proofs, aligning with the ever-changing nonces in SCRAM.

This journey underscores the delicate balance between robust security and effective software testing, highlighting the evolving landscape of digital security.

FAQ's

How can authentication issues with SCRAM be resolved in testing environments?

Authentication issues with SCRAM in testing environments can be resolved by ensuring that mocking tools are configured to handle dynamic nonce generation and server proof validation accurately. Keploy does this by aligning it's mocking capabilities with the authentication requirements of SCRAM, and ensuring authentication failures can be mitigated, and testing can proceed smoothly.

What are the key takeaways from exploring SCRAM authentication?

Key takeaways from exploring SCRAM authentication include:

SCRAM auth secures user verification without revealing passwords, enhancing security.
Mocking libraries may face challenges with SCRAM due to its dynamic nature.
Solutions for testing with mocking libraries involve configuring them with accurate server proofs and handling dynamic nonce generation effectively.
Balancing robust security with effective software testing is crucial in the evolving landscape of digital security.

How does SCRAM authentication compare to other authentication methods like JWT tokens?

SCRAM authentication is primarily used in connection-oriented environments like databases, whereas JWT tokens are commonly used in stateless services like REST APIs. Each method has its advantages and is suited to different use cases based on factors like security requirements and connection state.

What databases support SCRAM authentication?

SCRAM authentication is supported by various databases, including MongoDB, PostgreSQL, CouchDB, and others. It's becoming a standard method for securing user authentication in database environments.