On Jul 31, 2010, at 5:09 PM, Scott wrote: > In essence your argument is that it would take too much time and you > could change the hmac key monthly to prevent an attack. I understand > and respect that signed cookies are one way to solve the problem, but > I do not believe they are the "most correct" way. > > My analogy would be the difference between a handheld portable safe > (signed cookie) and a bank (server-side session). If your money is > stored in the bank, it's a lot harder to steal it because a thief > would need to break into the bank whereas a thief has all the time in > the world with a portable safe (which are also a lot easier to > break). With computer processing speed and algorithms (particularly > distributed computing) I am not sure that signed cookies will remain > as "safe" as they are today. With regard to changing the hmac key, > you are right they should be periodically changed although this would > need to be carefully planned as it essentially invalidates sessions > when it changes. I believe it would also would invalidate stored > encrypted data unless you use a one-time method to decrypt then re- > encrypt the data using the new hmac key. > > In summary, I believe server-side sessions to be more secure than > client-side cookies, period.
As a practical matter, I don't think it's much of an issue. A SHA-1 based HMAC, or SHA-2 if you're feeling especially paranoid, is not going to be cracked within the lifetime of a session. Notice that unlike encryption of sensitive data, cracking the session HMAC has no value once the session has expired. So the ability to attack it for months offline isn't of much use. The expiration problem could be handled by having two keys active at any given time, with their valid-time overlapped, so you have an 'old' key and a 'new' key. If someone comes in with an old key, replace the HMAC with a new version.
