5

Debating these two methods of storing session data:

Not sure which is more secure because after reading a little about the internals of node-client-sessions, there are a lot of potential attack vectors that need to be accounted for, and I'm not sure how much they account for. For example, they account for a timing attack by using a constantTime algorithm in one place. But there are many more potential vulnerabilities, and not being an expert I can't tell how well done it is as a library.

On the other hand, I have seen people say storing session id in the database is a no go. But at least here you could black list the session id.

Any advice or guidance would be greatly appreciated. Thank you.

4

The security difference will mostly be in the implementation details. Fundamentally both approaches are the same: you store a blob of data which is meaningless to the client on the client to preserve some state between requests. The difference is that session id cookies are in themselves meaningless because they do not represent any meaningful information, while the encrypted cookie is meaningless because the client does not possess the ability to decrypt the data.

Encrypted cookies are fundamentally more complex: they're larger in size, they require a complex algorithm, they require that algorithm to be correctly implemented, they do contain actual data and are thereby worth attacking, they do require the management of a secret key. They're also harder to revoke due to their decentralised nature.

Session id cookies are plain simple: a meaningless random id merely referring to data stored elsewhere. The only vulnerability* is guessability, which is easy enough to prevent by increasing the length and rotating and expiring ids. I have no idea why storing session ids/data in a database would be a bad idea in any way; as long as the database is secure, there's no issue there. If your data store is prone to attacks, you have bigger issues than where your session data is stored.

(* Aside from outright hijacking, which is the same vulnerability for all cookies, and implementation specific flaws like accepting undefined session ids etc.)

Given that, you need to decide whether the increased attack surface of encrypted cookies is worth the benefits of stateless servers, and whether you trust the implementation of the encryption. For high scalability I would seriously look into it, for small-scale services I would keep it as simple as possible.

2

Given that i just asked a question on crypto, i wouldn't peg me as an expert but:

a) If appropriately encrypted then the data in the cookie should be fine...

  • You are, at the end of the day storing the data on the end users machine. Not so great for shared machines but you can argue that the algo is most likely strong enough
  • If it's lots of data, you're transferring it to and fro with every page load, so you could slow down your application.

b) If you're using an SSL connection, a session ID should also be fine (with the appropriate length)

  • Regen session keys
  • Depending on your application, you can minimise the viewing of personal data. e.g. If you use the session to keep track of a users progress but don't present their information back to them (via the session), this could arguably be more secure.
  • You should be using SSL/TLS anyway, otherwise both types of cookies are basically broken. So that just leaves the length of the session id as vulnerability, and yes, it should simply be long enough. Overall I find this analysis a bit lacking. – deceze Nov 26 '17 at 8:25
  • deceze - not really. We're talking about encrypted data inside a cookie. If SSL isn't used then you can argue the data within it is still safe (encryption is done on another layer). A session ID within a cookie is not encrypted and thus absolutely requires SSL/TLS. – user164613 Nov 26 '17 at 23:54
  • TLS prevents the entire cookie from being hijacked! Both cookies are meaningless, you cannot “read” either cookie. But having either cookie is what identifies you. TLS is the non-negotiable baseline security for any cookie. – deceze Nov 27 '17 at 6:42

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.