> Also, about the cookies, you can definitely have a plaintext cookie saying userid=42, as long as it's signed.
Not necessarily good enough. If you just sign a cookie that says userid=42, anyone who ever manages to read it can now authenticate as your user whenever they like. You just turned any session hijacking attack into an account hijacking attack.
Do what tptacek says, "just use random tokens to key a serverside session store" and don't write your own crypto.
Wouldn't the random tokens also be vulnerable to a replay? If I copy a session cookie from one client to another, regardless of how that cookie authenticates itself, won't most servers accept it? Seems to me that once the client has been compromised, session hijacking is going to happen.
The server can be set to check that the client IP address and HTTP fingerprint match. That makes the replay attack harder but not impossible. It also introduces some usability concerns--valid sessions may expire sooner than intended.
The token is just a key to a server-side session that will be deleted eventually, for example when the client logs out. If someone can hijack a session, that's obviously already a problem, but unfortunately XSS attacks are fairly common as they are something that can happen in any number of places on a website, and even vigilant developers will probably miss some. (See, for example, the recent XSS attacks reported on Paypal).
If you use a random token to a session that will be invalidated, then the attacker is at least time-limited. If you just naively sign an auth cookie and trust it later, he has a replay attack that will work permanently until you change your code.
As for you other suggestion, restricting sessions by IP address can be done no matter where the session data is stored. It will help to mitigate session hijacking in general, but it also degrades the experience, especially for mobile users, who will have to re-login every time they change IP addresses. It's particularly a problem if a form submission fails for this reason, because they'll probably get redirected away to a login page and lose any information they entered.
Yeah, both this and the original article are vulnerable to replay attacks. A token is much better, but there are times when you don't want to hit the DB, such as for non-critical data like displaying the user's name on the page. Signing a cookie is reasonable then.
Not necessarily good enough. If you just sign a cookie that says userid=42, anyone who ever manages to read it can now authenticate as your user whenever they like. You just turned any session hijacking attack into an account hijacking attack.
Do what tptacek says, "just use random tokens to key a serverside session store" and don't write your own crypto.