2012/6/11 Derek <[email protected]>: > > > On Monday, June 11, 2012 1:31:47 PM UTC-7, mcm wrote: >> >> 2012/6/11 Anthony <[email protected]>: >> >> Does it make sense if we impose that the in cookie session can be >> >> enabled only on SSL session? >> > >> > >> > I assume the cookie is cryptographically signed so it can't be modified, >> > so >> > SSL shouldn't be necessary (though could optionally be turned on for >> > additional protection to keep the contents private). >> Knowing the application and its state can someone find the key since >> there is a single encryption/decription key? >> > I don't see why someone couldn't brute force it on their system once they > get a session. I suppose it would help to have the key change on a regular > enough basis for this to not be a problem.
Yes you need to change the key frequently. This should be done. I see a problem here, but maybe I am wrong. Once the encrypted session is sent back as a Set-Cookie header the encrypting secret must be kept until the server is able to receive a new request from the client with the Cookie header. We are talking about servers that need to answer to a very large number of requests. Do you have any suggestion? There is the classical solution of using an indexed table of pregenerated secrets, then include the index with the payload (i.e. the session), then change the key at each response. I suppose that would make things more safe, while not eating too much memory. > Seeing as how RC-5 72 bit key still hasn't been brute forced yet > (http://stats.distributed.net/projects.php?project_id=8) and that's using > 2000 computers for the past few years, they anticipate it will take them 90 > years to complete the project. So, 128-bit encryption with a key generated > on server start should be secure enough. By the time you break the > encryption, your key will be useless. This is the RC5-72 contest setup: "For each contest, the unknown plaintext message was preceded by three known blocks of text that contained the 24-character phrase "The unknown message is: ". While the mystery text that followed is known to a few employees of RSA Security, the secret key itself used for the encryption was generated at random and never revealed to the challenge administrators. The goal of each contest was for participants to recover the secret randomly-generated key that was used in the encryption." True. There is an important difference in that the session could be in a know state hence the secret could be guessed with a lot less effort. And once the key is guessed all the other sessions are compromised. But here is a possible simple solution: pad the serialized session with random data. That would make everything more secure. What do you think? >> >> > >> >> >> >> Could we also leverage the browser local store as an option? >> > >> > >> > How would the server access the session then? >> encrypting its content with a once from server and sending back >> encrypted data in a header? >> >> > >> > Anthony > > > On Monday, June 11, 2012 1:31:47 PM UTC-7, mcm wrote: >> >> 2012/6/11 Anthony <[email protected]>: >> >> Does it make sense if we impose that the in cookie session can be >> >> enabled only on SSL session? >> > >> > >> > I assume the cookie is cryptographically signed so it can't be modified, >> > so >> > SSL shouldn't be necessary (though could optionally be turned on for >> > additional protection to keep the contents private). >> Knowing the application and its state can someone find the key since >> there is a single encryption/decription key? >> >> > >> >> >> >> Could we also leverage the browser local store as an option? >> > >> > >> > How would the server access the session then? >> encrypting its content with a once from server and sending back >> encrypted data in a header? >> >> > >> > Anthony
