Highlight that the session replay strategy prevents a user from being logged into multiple devices at once. about rails-authentication-from-scratch HOT 6 CLOSED

From what I know, there is no way to fully mitigate the session fixation issue with only cookie-based sessions. When a cookie is stolen, you are logged in. Maybe you can solve this with an HMAC signed message in the cookie with an expiration token. But this expiration time should be short in order to minimize the effect of session fixation.

We have always opted for storing sessions in the database. Logging out means deleting the session record from the database, so no one is able to use the session id anymore. When privilege level changes occur, you can easily stop all sessions for the user. This is what the current implementation is currently doing. I would never implement this in an application, it is a guarantee for angry users that need to log in again and again.

from rails-authentication-from-scratch.

@edwinv thank you for your insight here!

We have always opted for storing sessions in the database.

Do you have an example of this? I've seen this mentioned in the guides, but I don't think I'm understanding it correctly.

This is what the current implementation is currently doing. I would never implement this in an application, it is a guarantee for angry users that need to log in again and again.

Are you referring to the fact that during login and logout we're resetting the user's session token?

from rails-authentication-from-scratch.

@edwinv thank you for your insight here!

We have always opted for storing sessions in the database.

Do you have an example of this? I've seen this mentioned in the guides, but I don't think I'm understanding it correctly.

When the primary source of the session is a cookie, everyone knowing the cookie is effectively logged in. This is also described in the Session Storage chapter in the security guide. Cookies are an easy start for session management, but for more critical applications it's not secure enough. Rails has the option to change the session store. Switching to a server-side store, like Memcached, Redis, or a database, allows you to really delete the session from the storage when a user logs out. Even when an attacker gained access to a session id, it will still be invalid after logout.

This is what the current implementation is currently doing. I would never implement this in an application, it is a guarantee for angry users that need to log in again and again.

Are you referring to the fact that during login and logout we're resetting the user's session token?

Yes. This behavior imitates a database-backed session store, but with the downside of resetting all sessions of the user. When you switch to another session store, you can effectively reset a specific session during login and logout. And after changing the email address, password, or other permissions, you can log out all sessions of the specific user.

from rails-authentication-from-scratch.

This is very helpful, thank you for the insight!

I think for now I will highlight the following:

• The session store can be configured, and that there are advantages/disadvantages to each type of store.
• The current strategy prevents a user from being logged into multiple devices at once, but at the cost of better security.

Do you think I need to actually implement these strategies, or is highlighting them enough? I think Devise uses the default cookie session store, but they don't rotate the session token.

from rails-authentication-from-scratch.

I always prefer to keep things simple, so I would stop using the current strategy with a single token and just use the plain cookie setup. Mention the disadvantages as you suggest, this allows people to make a choice of their own.

If you keep the session token, switching to another session store means you need to disable this session token before you have all benefits of multiple sessions per user in the new store. This means extra work and could cause bugs. When a user needs the added security, switching the session store is a simple configuration change without other changes to your implementation.

from rails-authentication-from-scratch.

@edwinv thank you for your help with this. For now, I've updated that section by adding more context based on our discussion.

The goal here is to highlight that setting a user's id in the session isn't as secure as using a rotating value or using a different cookie store.

I'll leave it up to the individual to determine if this is something they'll want to implement.

from rails-authentication-from-scratch.