True, the PCI-DSS mandates things like that, such as tokenizing credit cards and only passing the tokens, using a centralized secure database to store the data, etc. WRT the site cookie, you'd have access to what that user has been authorized to see, sure. There are other standard-practice methods like associating the IP address to the session (again, built into web2py)... I just happen to be paranoid about these types of things and would rather give out as little information as humanly possible to the client. That is to say, only the session token. Call it the Principle of Least Information =) WRT this not being an issue on today's hardware, sure I agree. I have a tendency to look for what not only works today but works for the future to prevent having to redesign the system a few years down the road. I'd rather do the hard work now to pay dividends down the road.
So how about a compromise - let's switch to using secure, HTTPOnly, signed and encrypted cookies which store the session token and give the programmer the option to store some data in the cookie if required. Just put a caveat that the least amount should be stored (and in any case, less than the 4k limit). On Jul 31, 8:38 pm, Thadeus Burgess <thade...@thadeusb.com> wrote: > @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.
