Ambush Commander wrote:
As a user who has my browser to ask me whether or not I want to accept a cookie, I severely dislike sites that shower cookies upon you (especially the ones that are like: Site would like to send a cookie named "test"). Adding extra session cookies helps, but only to a small extent after the second, because if they got one cookie, then they've probably got them all.
I completely agree. Anything beyond sessioncookie (which, being temporary, wont prompt you in some browsers), and a username token means you are doing something wrong.. ie, store it in the db instead.
nielsene wrote:No I didn't, I said HMAC(sessionID.expTime) (concatenation) my implementation of HMAC pulls the server secret from a constant, not from an argument. So it is sstill an HMAC and not a simple hash.
Even with concat, its not a secret. Now, if in fact there is an additional secret, which you aren't listing in that equation, thats different. In the scenario, sessionID is known, expTime can be reliably guessed, and a concat of the two isn't exactly rocket science. Which server secret are you talking about?
nielsene wrote:Only when you have the seperate username authenticator token. Without that you have no session protection.
Again, don't mistake "less" protection with "no" protection. Even without the username token, you are still dramatically reducing the window for attack with session regeneration. Granted, thats still leaving an exploitable window, but its smaller, and thus, it is more protection. (And it is industry best practice to persue that smaller window).