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. On Jul 31, 2:39 pm, Thadeus Burgess <thade...@thadeusb.com> wrote: > To crack a signed cookie you need the secret hmac key that is usually > stored within the application. Brute forcing an hmac key will take > more time than any hacker has, especially if you change it once a > month or so. > > -- > Thadeus > > On Sat, Jul 31, 2010 at 1:00 PM, Armin Ronacher > > > > > > > > <armin.ronac...@active-4.com> wrote: > > That is incorrect. That is indeed true for a regular cookie, bit that > > has all kimds of problems. I was referring to actual signed cookies. > > > On Jul 31, 9:56 am, mdipierro <mdipie...@cs.depaul.edu> wrote: > >> There is a difference. > > >> If you have a uuid sessions cookie and a serverside session and an > >> attacker hijacks the cookie, he can only get access to the account of > >> the compromised user. > > >> If the session is stored client side and the attackers hijacks the > >> cookie, he can tamper with the data in the session and, depending on > >> what the session cookie stores, may get access to more than data of > >> the compromised user. > > >> Massimo > > >> On Jul 31, 1:58 am, Armin Ronacher <armin.ronac...@active-4.com> > >> wrote: > > >> > Hi, > > >> > On Jul 31, 2:38 am, Scott <blueseas...@gmail.com> wrote:> I do not agree > >> > with item 1. Session data should never be stored > >> > > client-side as it opens a rather large attack vector. > > >> > Which attack vector exists for signed cookies with a signed timeout > >> > compared to just session IDs in cookies? Both can be hijacked by a man > >> > in the middle. > > >> > Regards, > >> > Armin
