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

What is the advantage to hashing a user id and storing it in the cookie over simply generating a random session code and storing it in a db table against the user's id and then checking every request? Is the overhead of an extra db read the only reason people don't do this? (Honest question, not trying to be smart)


Well, in order to protect the hashes in said cookies you would end up doing something similar to prevent malicious users from just spoofing them. If you use id/hash tables the way you propose the hash is acting just like an id and is then vulnerable to the same issues. The problem is not that the id is there, but that you need a method to make it hard to spoof.


No, you have mosunderstood me. I'm NOT storing a hash in the cookie. Instead im storing a random string. Because this string is random, there is no way that a malicious user can guess what the session code will be for a particular user id.


> Is the overhead of an extra db read the only reason people don't do this?

Yes, and using secret_token.rb is also way faster.


that would couple session to db. Play Framework, for example, is able to provide support for sessions using encrypted cookies, without having to provide adapters to all sorts of potential databases.




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

Search: