4 ms·

I found this: http://www.cse.msu.edu/~alexliu/publications/Cookie/cookie.pdf http://www.cse.msu.edu/~alexliu/publications/Cookie/cookie.p... here: http://securi

I found this: http://www.cse.msu.edu/~alexliu/publications/Cookie/cookie.pdf http://www.cse.msu.edu/~alexliu/publications/Cookie/cookie.p... here: http://security.stackexchange.com/questions/7398/secure-session-cookies http://security.stackexchange.com/questions/7398/secure-sess... And implemented it. It was quick, cheap, and easy enough for me to assign a new token with most (if not every) request that required authorization/authentication. The only bits of info kept in the cookie were insensitive bits of data, so if a single token got cracked it wouldn't be a huge deal.

iheartmemcache 10y ago
Re-issuing tokens sounds like a poor-man's nonce. I skimmed the pseudo-code in their paper, immediately said to myself 'uhh..', then a section later they addressed my 'uhh..' by admitting replay attacks are effectively trivial. In some cases, no security is better than bad security, because at least your users are aware of the insecurity. (Granted, you're protecting against the replay attack - my point still stands for anyone even considering implementing something based on that paper.)