Secured server side session management @SplashLearn

Overview: This article capture basics of session management and our experience migrating to service side session management at Splashlearn.

First of all, what is session management?

Session management provides a way of storing user-specific information between page requests. A unique session id is stored to identify a specific user. Most web-based application have users who log-in in their application needs authentication and session management to figure if the same person requested two different pages or not.
Usually a session starts when a user provides valid authentication details to the web-based applications and ends when he logs out or the session becomes stale due to inactivity. Sessions may also store some data that can used across pages for personalization and/or enrichment.

How sessions used to be managed at SplashLearn

SplashLearn’s authentication and session were managed by a gem (library in Ruby on Rails) called Devise. The default session store for Devise is cookies, which means each session’s user-specific data was stored in the browser’s cookies. The session data was encrypted with a “password digest” to protect against tampering using a server-side secret key.
While signing in, a user’s credentials were validated by matching them with the hashed credentials stored in the database and the encrypted session data was stored in cookies. The browser would store those cookies and whenever the user would make a request to our application, that request will also automatically include the session data in the cookie (along with the other cookies), which would then be authenticated at the server end. Until the cookie expires or the user logs-out manually, the browser would send the cookies to the server with every request.

Why did we move to server-side sessions?

One of the major reasons was to improve the security of our user’s account. In our internal security vulnerability assessment, we identified session related security vulnerabilities in our application and hence on moving to server side session we were able to have following advantages:

1. Invalidation of authentication cookies at logout.
2. Validation of data at server side which prevents from cookie modification at client side.
3. Logging out one or multiple sessions of a user from the back-end.
4. Limit the number of sessions of a user or block multiple logins at the same time.
5. Able to have deeper analysis on user sessions.
6. We are able to store a larger amount of session data as cookie size is limited to 4 kB.
7. Use session data for any type of personalization.

Note: We would still need to pass cookies as a session reference needs to be maintained.

How we implemented server-side sessions at SplashLearn

We used Redis to store our session data because of its persistent and super-fast performance with read and write operations. It takes less than a millisecond as it’s an in-memory storage.
We decided to create two data types in Redis to provide the aforementioned features.

1. db_session — It is a key value pair. It stores an entry for every session created by the user in which the key is a unique 32 character long alphanumeric string called session key with the user’s id as value. Multiple entries are created for multiple sessions of the same user.

2. user_db_sessions - It is a Redis Set, which is a collection of unique string(session keys) elements. It is highly efficient as it provides O(1) time to add, remove, and test for existence of members.
It gets an entry every time the user log-ins into the system where the key is added as the user id and value as the session key added in the db_session hash.

Following methods with pseudo code are exposed:

Integration with Devise gem and Warden in Ruby on Rails.

Devise is based on Warden, which is a general Rack authentication framework in Ruby web applications. It fits into the Rack-based architecture and provides powerful options in the form of callbacks at various points in the authentication cycle.
We also added a read-only flag to prevent users from logging out when we take our code to production as initially there would be no entry in then session database. This will allow us to keep adding entries of active sessions in the database.

Hope this post helped you.
Happy coding and sharing :)