

Ask HN: Client side or server side sessions? - codegeek

I have been doing a lot of reading lately on sessions and cookies. I am almost obsessing over web security while learning Python/Flask and building some small apps to teach myself.<p>I know there is probably not a one size fits all kind of answer for this but what are the pros and cons of client side vs. server side sessions ? I was thinking of building server side session (using redis). Thoughts?
======
martinml
Client-side sessions are nice because they are simple and you don't need a
backend in your server.

But they have cons too:

\- If a user changes his password, other sessions will keep active until they
expire. This is a problem when (and not if) an account gets compromised. You
can fix this easily, for example, including a token for each user that changes
when changing the password, but then it defeats the point of client-side: you
have to store the last token somewhere in your server.

\- With the default implementation of Flask, if your secret key somehow leaks,
apart of the obvious problem, anybody could execute arbitrary code in your
server. You can fix this easily and without any serious consequences (apart
from kicking out all your already logged users) by using JSON to serialize the
cookies instead of Pickle: <https://gist.github.com/2501926>

\- You are limited to 4 KB of data. In a server-side solution the user has
only a session ID that gets associated to all the data you want in your
database.

Related discussion:
[http://flask.pocoo.org/mailinglist/archive/2011/8/15/securit...](http://flask.pocoo.org/mailinglist/archive/2011/8/15/security-
of-secure-sessions/)

~~~
codegeek
Thanks I have looked through this already. I even used the snippet to use
itsdangerous module which seems more secure. But how do I tie all that in a
session ? More importantly, client side or server side?

~~~
martinml
I don't know if I understood your question correctly. If you use Redis (or
whatever backend) you don't need to sign the cookie with itsdangerous (or
whatever module). You just generate a SID and stick it into a cookie:
<http://flask.pocoo.org/snippets/75/>

------
pixelcort
Assuming your client-side sessions are stored in cookies, be aware of doing
multiple simultaneous requests. The order in which the server processes them
could be different than the order the client processes the results. This can
lead to overwriting a session with an older version of the same one.

Unless you are only doing one request at a time or you don't mind rolling back
to older session data, avoid cookie-based client side sessions.

~~~
codegeek
I have decided to go with server side session to store session data. But I
will use signed cookie to transfer the session id b/w client/server.

------
kls
What I have opted for when doing modern web development is to eschew the idea
of session all together. Decoupling authorization and authentication from data
storage is one of the advantages while the other is that you do not run into
the standard anti-patterns that session creates on the web. With AJAX style
request you can exchange authentication and authorization tokens like SAML or
oAuth. This can be done by adding authorization headers to the payload, and
employing some form of salted encryption. Given that I am not a security
expert, I tend to use patterns and encryption algorithms that the security
community has endorsed. Some of the more comprehensive JavaScript frameworks
like Dojo have crypto implementations. From there I tend to use a cache on the
client side, to store transient data that needs to live from request to
request and cannot be retained in memory for whatever reason.

------
thiagodotfm
You don't understand sessions, it seens.

~~~
codegeek
If you don't mind explaining, I would appreciate. I seriously want to learn
and understand about sessions and best practices. been googling and reading
for last 2 days.

------
kuasha
>>I am almost obsessing over web security ..

If you need more security why not use https all the time and better use two
factor authentication?

BTW, would you mind explaining what is a client side session? Share a link may
be? Really, I have never heard of them-

~~~
codegeek
By client side session, I mean that the session related data will be stored on
client side (in a cookie) instead of server side (database, files etc.).

~~~
georgemcbay
Generally speaking when it comes to any client-server communications, nothing
stored on the client can be trusted to be unaltered out of band from your
application logic.

There are very few situations in which I'd store anything on the client other
than a basic session id representing server-side state.

------
codegeek
This is what I have settled on so far btw.

1\. Store session data on server side (use redis for storage)

2\. Only exhcnage session id b/w client and server using cookies (serialized
using pickle ?)

3\. Regenerate session id after login ? Is this needed though ?

