Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Isn't the whole problem in this situation that you are trusting the client with critical data? He takes possession of it, has unlimited time and opportunity to work on it, and successful falsification will be obvious for him? Why on earth trust the client with the data in the first place? I have never liked the "encrypted cookie" way of handling session storage.

Just have a server side session store and all of this cookie encryption crap just vanishes. Of course that won't help you with session fixation etc, but the post doesn't address that stuff either. Do it over TLS and you're pretty safe though.

And let's not forget the author's suggestion to pad out the cookie with 1000 bytes to make it harder to falsify. That cookie gets send with every single request. 20 images on the page, you're sending 20KB of junk up just to load the page. On a connection with slow upstream, like say ADSL, you can easily add a second or two of request latency. You might not care but some people sure do.

And come on, I read until the very end expecting to hear what "processes or threads" have to do with security, so tell us already!



I don't think you read this post carefully. The "padding out the cookie with 1000 bytes" thing is what an attacker does to break your cookie. The "processes or threads" thing is a very cryptic in-joke. Sorry. Like I said, there are aspects of this post I didn't think would carry over to HN (actually, I didn't think any of it would).


Not to feed this rant too much, but I believe the cookie would be used for verifying a cross authentication attempt. Not exactly sure how it would be used but I'm pretty sure once you've got a session going on both servers the original token would be removed.

Also processes vs threads was just another interview question, it was only slightly more relevant to the story than unicorns in space.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: