nielsene wrote:The mac ensures that a user can't change either the id or the expTime associated with the token and that the token is basically atomic at the user level.
Right.
The php exptime can't be changed by the user at all - its handled server-side by php. Thats why id+exptime (hmac'd or not) is of no advantage over php's sessionid.
nielsene wrote:So this is more of a defense against session hijacking via guessing/morphing a known session id, than a sniffing/replay attack.
Thats definitely a different problem.
In PHP's session id, if the attacker guesses a good session id, he's still going to need a valid session variable - perhaps username - to match. If he doesn't, the application should reject him.
In your session id, its no different - if the attacker can get the session id, the exptime is simply another value he has to guess, much like the missing matching username from php's session id scenario above. Not to mention, by flooding the webserver, the attacker can get an extremely reliable/predictable exptime. From there, creating an hmac of it and the session id is trivial.
All told, it really doesn't hold much advantage.
nielsene wrote:Its possibly to avoid the replay attack vector by adding a nonce to the token
Its important to note that you are leaving out the key behavior that makes a nonce valuable - non-repeatability. The session id doesnt change. The exptime does, but you can retry (repeat) values over a period of time. If you couple that with flooding the server, you can get an extremely reliable exptime, which is your nonce. Thus, its not a proper nonce. A proper nonce 'locks out' repeated attempts of the same nonce.
nielsene wrote:To close the sniffing vector, configure php to only use cookies for session and then only send cookies via SSL.
Alternatively, you can use a solution that works regardless of SSL's presence: session regeneration, limited session times, and db-driven sessions.
nielsene wrote:
This method does help in a shared hosting environment where people can see the names of the temp session files, while they can "guess" the session id with 100% certainity, they don't have the hash so the session is invalid.
Read above about how to get a reliable ExpTime hash. Its not common, but it is used. DB-driven sessions on the other hand solve the shared hosting problem perfectly.