Enhancing Shiksha Authentication- JWT

Author : Sumit Kumar

Shiksha has undergone a significant transformation in its authentication system, moving away from the traditional cookie-based login approach that posed several limitations. In the previous system, user information was stored within cookies, with inherent security vulnerabilities. Users’ cookies could be easily copied and pasted, allowing unauthorized access to accounts when intercepted during network transmission. Moreover, there was no efficient way to log out users from the backend or specific devices. Cookie integrity and modification detection were challenging, leaving the system susceptible to tampering.

With the transition to a more advanced authentication system, Shiksha has eliminated its dependency on MySQL for validation. Instead, the method now leverages Redis, offering greater flexibility and control over user sessions. This upgrade allows for real-time adjustments to session expiration, aligning with evolving security policies and product requirements. Additionally, the new system empowers Shiksha with enhanced security measures, including robust mechanisms for managing maximum device logins.

Overall, this transition represents a significant step forward for Shiksha, ensuring improved security, user management, and adaptability in an ever-evolving digital landscape. By addressing these limitations head-on, Shiksha has reinforced its commitment to safeguarding user data and delivering a more secure and user-friendly experience.

1. The old cookie-based login system allowed for easy unauthorized access, as anyone with access to a user’s cookie could log in, posing a significant security risk.
2. Logout functionality from the backend or specific devices was lacking, making it challenging to manage user sessions.
3. There was no effective method for detecting if cookies had been tampered with or modified.
4. The old system relied on MySQL for validation, which has since been replaced in the new system.
5. The migration to Redis provides greater control over session expirations, allowing dynamic adjustments to align with security policies and product needs.
6. The new system introduces enhanced security measures, including mechanisms for managing maximum login attempts and bolstering overall security.

Old Cookie Validation

In the earlier Shiksha authentication system, when a user logged in or signed up, a cookie was generated and stored in their browser. This cookie contained essential user information for validation purposes. However, over time, this practice has come to be regarded as less secure due to the exposure of sensitive user data in a visible and accessible cookie.

The process was straightforward: once a user logged into the system, subsequent requests that required validation would rely on this ‘user’ cookie. If the validation was successful, the user would be granted access to their account. While this method served its purpose, it had a critical vulnerability. If an attacker managed to copy a user’s cookie, it remained undetected, allowing both the legitimate user and the attacker to stay logged in simultaneously.

This security flaw was a significant concern, as it could potentially compromise user accounts and data. Shiksha recognized the need for a more robust and secure authentication system, prompting the transition to a more advanced approach that addresses these vulnerabilities and provides enhanced protection for user information.

Enhanced Approach — JWT

Token Creation Process

• First, check if the user is blocked/deleted. If yes the return from this step.
• First, we create a refresh token, each refresh token is n-length random alphanumeric text.
• Then we save this refresh token in Redis against the userID. If the max device login limit has been reached then based on LRU policy we log out of the first device.
• Once the Refresh Token is saved in Redis, we create an Access token making the above saved Refresh Token as keyID, subject will be UserId, and expiry of the token will be X Month/Year.
• Now the Token is Signed using SHA-512 and a Secret Key. And Tokens (Access & Refresh) are sent back to the user.

How Refresh Tokens Are Stored in Redis

There are two pieces of information that we maintain for each user :

• First a key JWT:ID maintains a list of refresh tokens against each device where the user has logged in. There is a limit on max device logins which currently defaults to k.
• Against each Refresh Token we maintain yet another Redis key JWT:ID:RT, this key contains a list () that maintains a history of refresh token life (we call it Refresh Token Chain). For example, let's assume our refresh token is A, if we refresh the token we get B, then the chain will be A -> B -> C -> D. In this list top most (D) is the most recent token that is active, if we detect that someone has tried to use old tokens (A, B, C) then this is the case of identity theft, so we logout both legit & non-legit users.

Token Rotation

To fortify our system against the threat of copied user cookies, we’ve implemented a robust token rotation process. This multi-step procedure is designed to enhance security and thwart potential malicious activities. Here’s a breakdown of how it works:

1. Refresh Token Endpoint: Our system exposes an endpoint through a gateway Service, which plays a pivotal role in the token rotation process.
2. Access and Refresh Tokens: The endpoint requires the submission of both an access token and a refresh token to generate a new refresh token.
3. Access Token Validation: The process begins by validating the access token’s authenticity. If the access token is valid, we extract a unique identifier known as the keyID, which corresponds to the refresh token.
4. Refresh Token Verification: Next, we compare the extracted keyID (refresh token) with the refresh token provided in the API call. Additionally, we verify if this refresh token is the most recent in the rotation chain and if it exists in our Redis database.
5. Token Regeneration: If all validations pass successfully, we proceed to create new access and refresh tokens. This updated token information is then stored in Redis.

How Token Rotation Thwarts Cookie Copying:

Let’s illustrate this concept with an example. Suppose a user logs into our system, resulting in the issuance of a ‘user’ cookie. Now, consider an attacker who manages to copy this cookie and attempts to use it. Token rotation can occur in two scenarios: when the legitimate user initiates it or when the attacker does (if they are accessing the website via a browser).

Genuine User: If token rotation is triggered by the genuine user, the attacker’s copied token becomes outdated in the token refresh list. When the attacker tries to log in with these now outdated tokens, the system identifies a breach and takes action. It logs out both the genuine user and the attacker from the device where the token was copied, ensuring account security.

Attacker: When the attacker initiates token rotation, they acquire a new refresh token, while the genuine user retains the old one. Since the attacker possesses the new token, they can use the system without issue. However, when the genuine user attempts to access the system using the old token or tries to refresh it (which is now outdated), the system detects the token’s age. Consequently, both users are logged out from the specific device, ensuring protection against unauthorized access.

This token rotation mechanism provides an additional layer of security, making it significantly more challenging for attackers to exploit copied cookies and enhancing the overall safety of user accounts and data.

Sign out

When the user logs out from the website we first delete the refresh token from Redis and also delete the refresh token chain.