@Scott, I think your argument is based on assuming a bad programming design. If you have any type of data that needs to be secure to that detail, I hope to god your not storing them in the session in the first place! I mean, if I somehow copy your sites cookie from a user, I now have access to the entire site anyways.
You should only be storing data in a session that won't compromise your data in the first place. Userid doesn't mean anything even if the cookie was cracked (though on todays hardware would take 900 trillion years to crack a good hmac key). If your storing an encrypted tree of credit cards in the session, don't you think it would be appropriate to redesign your application and store that in the database instead? Not to mention, google, facebook, twitter, microsoft, quicken, chase, capitalone, visa, etc. etc.. all use signed cookies... They are the "most correct" way to do it on todays hardware, and todays software, and todays browsers. Perhaps when we have flying cars it won't be the best way anymore, but until then =) -- Thadeus On Sat, Jul 31, 2010 at 7:28 PM, Jonathan Lundell <jlund...@pobox.com> wrote: > 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.
