loading...

What's the recommended method for designing secure and performant web sessions in 2018?

eronaeon profile image eronaeon ・1 min read

Hi all! designing sessions is very essential for all modern webapps, however there is very little discussion about it. Let's assume that a webapp uses HTTPS by default (i.e. no worries about eavesdropping or modifying cookies).

Let's say I just want to design a session that stores only user id, what's the best method to design sessions? from what I know:

Web based sessions:

clearly the main disadvantage is I have to go to the database every http request and check the session ID. Sure I can use Redis to cache session ids, but also I have to implement a write through logic if I happen to update the session content so that Redis and the DB are synchronized

Django's approach

just generate a random session id (long enough let's say more than 20 ascii chars) and store it in a cookie.

Express session's approach

same as Django but also adds HMAC to the session id cookie (isn't this redundant for a HTTPS connection?)

Client based sessions:

JWT

lots of hate and critic about it even though it sounds pretty secure and more performant, and I am not sure how many respectable websites that actually implement it


What do you recommend? what's the current recommended method for designing session logic for a website (hopefully that could be extended to a mobile app) in 2018?

Discussion

pic
Editor guide
Collapse
rhymes profile image
rhymes

Don't you still need the server side if you only store the user id? If you store a single token / user id / session id you still need to look that up on the server.

If you need to keep a user session, what's wrong with just using sessions :D ?

I'm not sure with which technology you're programming but basically every major framework has the session management logic for free and, for example with Rails, you can handle cache and db more or less transparently.

Collapse
eronaeon profile image
eronaeon Author

Don't you still need the server side if you only store the user id? If you store a single token / user id / session id you still need to look that up on the server.

Yes, but if I use server based sessions, I have to lookup the session id from the session table first, then get the user id from the session content, then lookup the user by its id in the users table. I have to do an additional lookup in the database for each request. But with JWT, I already have the user id inside it.

Collapse
rhymes profile image
rhymes

It depends on what you want to do.

If on the client there's only the user id and no other information you don't need JWT, you can just use a join on the server to issue one select to find the data from the session id.

If you "trust" the JWT token containing a user id and that's your only entry point to validate the user session then you have a security issue because if the JWT is stolen first you won't know it and second the attacker can impersonate the other person.

This is my favorite post on the topic of JWT: cryto.net/%7Ejoepie91/blog/2016/06...

Anyhow in general I wouldn't recommend creating your own authentication framework, at least for security reasons is more like that battle tested frameworks have more eyes on that issue.

What framework are you using?

Thread Thread
eronaeon profile image
eronaeon Author

you can just use a join on the server to issue one select to find the data from the session id.

thought of doing this, but this means I will end up writing my own session logic anyway, right?

If you "trust" the JWT token containing a user id and that's your only entry point to validate the user session then you have a security issue because if the JWT is stolen first you won't know it and second the attacker can impersonate the other person

Doesn't this apply exactly the same to server based sessions? If the session id or the cookie containing the session id was stolen, the attacker can very easily impersonate the victim just by adding it to his cookies.

What framework are you using?

I am using Express 4/Node.js

Thread Thread
rhymes profile image
rhymes

thought of doing this, but this means I will end up writing my own session logic anyway, right?

Exactly, which I would avoid.

Doesn't this apply exactly the same to server based sessions? If the session id or the cookie containing the session id was stolen, the attacker can very easily impersonate the victim just by adding it to his cookies.

Yes, exactly. So why not just use an existing implementation? JWT are not secure by default, you need to put them in a secure httponly cookie which is basically what you're going to accomplish by using sessions anyway.

JWT is just a token, it's not magically secure.

For Node.js maybe Express Session will do?

A tutorial: medium.com/of-all-things-tech-prog...

ps. I'm not trying to say "never use JWT" it's just that I don't see the benefits in this particular case

Collapse
eronaeon profile image
eronaeon Author

those people reacting to the post without any discussion are really weird, do you think this is an article or something?